[00:34] <mhall119> anybody else missing their message indicator?
[06:48] <Saviq> mhall119, yeah, not here for me either
[08:21] <Saviq> mzanetti, hey, so there's one more possibility of going about the "I need to call a method on the object" - which is proxying the call through the model - I wonder if that would be cleaner
[08:22] <Saviq> mzanetti, i.e. Class::myMethod() would be proxied through ClassModel::myMethod(int index)
[08:22] <Saviq> mzanetti, but then there's proxies
[08:23] <Saviq> mzanetti, so as soon as you proxy a model, fail unless you expose the object in the model itself
[08:24] <mzanetti> Saviq: yeah. that's what I do with the Launcher
[08:24] <mzanetti> Saviq: that's only an option for a limited amount of methods
[08:24] <mzanetti> Saviq: and also not an option for the "passing items outside the scope of the model roles" thing
[08:24] <Saviq> mzanetti, right
[08:25] <Saviq> mzanetti, ok, so let's see if Q_DECLARE_TYPE helps, in which case I'm opting for exposing the objects through the model
[08:26] <mzanetti> Saviq: setting up an example now
[08:26] <Saviq> mzanetti, thanks
[08:37] <nic-doffay> Saviq, any more thoughts as to why the label changes in your comments on the option selector review?
[08:38] <Saviq> nic-doffay, If I'd have to guess, it's because the divider is enabled/disabled
[08:38] <Saviq> nic-doffay, when you expand / collapse
[08:45] <mzanetti> Saviq: hmpf... can't reproduce the issue :D
[08:45] <Saviq> mzanetti, lol :P
[08:46] <mzanetti> Saviq: do you know of a place where we had it?
[08:47] <mzanetti> Saviq: here's the example code... lp:~mzanetti/+junk/model-get-test
[08:52] <mzanetti> Saviq: ok... if I use qmlRegisterType on the Item and import the uri for that, everything seems to work. If I don't do that, I get this kind of messages: TypeError: Object QVariant(FooItem*) has no method 'value'
[08:52] <mzanetti> Saviq: but I can't believe this was the issue. I'm sure we did the qmlRegisterType
[08:52] <Saviq> mzanetti, no, I never saw that issue ;)
[08:53] <Saviq> mzanetti, our issue was that moc didn't know namespaces
[08:53] <Saviq> mzanetti, in the Launcher API
[08:53] <Saviq> mzanetti, so you had to make the return type explicit
[08:53] <mzanetti> hm... that was another issue. Don't think its related to this. but I can try
[08:54] <Saviq> mzanetti, I don't remember having the "QVariant clash" issue
[08:55] <mzanetti> Saviq: I remember that MacSlow ran into it with the notifications
[08:56] <MacSlow> Saviq, mzanetti: can't recall the solution/workaround atm
[08:57] <mzanetti> MacSlow: well, we know the solution. We're just not able to reproduce the issue :D
[08:57] <Saviq> ;)
[08:57] <MacSlow> mzanetti, Saviq: it could be worse :)
[08:58] <mzanetti> one would think so, yes
[08:58] <mzanetti> not entirely sure about it in this particular case
[09:02] <mzanetti> MacSlow: where can I find the code for the notifications backend?
[09:02] <MacSlow> mzanetti, bzr branch lp:unity-notifications
[09:11] <mzanetti> Saviq: pushed some more code to that junk repo. should be able to rest every use case with that. However, I really can't recall any more what exactly was the usecase where returning the pointer wrapped in a QVariant didn't do.
[09:11] <mzanetti> but I'm 100% positive that there is an issue somewhere
[09:12] <Saviq> mzanetti, thanks
[09:20] <larsu> dednick: did you get started on the action stuff yesterday?
[09:20] <dednick> larsu: yeah, but hit a snag with the ext attributes
[09:22] <larsu> dednick: hm? Those are on the menu items, not the action...
[09:23] <dednick> larsu: yeah. kind of tangented onto another problem. let me get you the action shizzle quick.
[09:27] <dednick> larsu: http://pastebin.ubuntu.com/5928350/
[09:27] <dednick> larsu: it includes the action state parser stuff as well.
[09:28] <larsu> dednick: I already merged that :)
[09:28] <larsu> dednick: but don't worry, I'll sort it out
[09:29] <dednick> larsu: hang on. it's missing a few bits i think
[09:29] <dednick> forgot to bzr add
[09:39] <Saviq> mzanetti, so, do we agree get(int index) is unnecessary in the end?
[09:39] <Saviq> mzanetti, and exposing the object through data() is ok?
[09:39] <mzanetti> Saviq: not sure yet
[09:39] <Saviq> mzanetti, still trying to find the issue?
[09:40] <mzanetti> Saviq: no... gave up for now. but I can't believe I introduced the get() methods for no reason. There is something fishy in there.
[09:40] <Saviq> mzanetti, maybe it's simply a bug that was fixed since?
[09:41] <mzanetti> Saviq: that could indeed be
[09:48] <Saviq> mzanetti, so, since we can't find issues, do we agree we're fine with exposing objects through models?
[09:48] <Saviq> tsdgeos, maybe you want a deciding vote ↑?
[09:49] <Saviq> tsdgeos, for context read last paragraph in https://docs.google.com/a/canonical.com/document/d/1gd87Wo_CSB0DpFWLpTKIIXQfdmFncrq0PHSr9H2PTnk/edit
[09:49] <mzanetti> Saviq: I'd say yes... in case I just missed it in my tests now and it's still present its most likely anyways one of us 2 that runs into it at first
[09:49] <Saviq> tsdgeos, the commented entry about wrapping QObject*s in QVariant<QObjects*>
[09:50]  * tsdgeos reads
[09:50] <dednick> larsu: http://pastebin.ubuntu.com/5928409/
[09:51] <dednick> larsu: merged with latest.
[09:52] <dednick> Saviq: do you know if it's possible to get the model back from the modelData in a listview delegate?
[09:52] <tsdgeos> Saviq: yeah, don't see why data() should not work, i mean we do it in several places already
[09:53] <Saviq> dednick, you need to expose it as a role
[09:53] <dednick> Saviq: thanks :(
[09:54] <Saviq> dednick, why :(
[09:54] <tsdgeos> Saviq: fwiw i have touch in shell and apps in gerry's demo shell
[09:54] <tsdgeos> now having a look at the real shell :D
[09:54] <Saviq> tsdgeos, awesome
[09:54] <Saviq> tsdgeos, if we get it for tomorrow, would be awesome (we're doing demos for Jane)
[09:54] <tsdgeos> demo shell == http://bazaar.launchpad.net/~gerboland/+junk/qml-demo-shell/
[09:54] <dednick> Saviq: meh. that sounds a bit silly.
[09:54] <Saviq> dednick, a Model doesn't know what it's backed with, there needn't even ba a model back there
[09:55] <dednick> Saviq: you mean the data does know?
[09:55] <dednick> doesnt
[09:56] <Saviq> dednick, I mean that a ListModel doesn't even have to be backed by anything
[09:56] <Saviq> dednick, it can be built on the fly
[09:57] <dednick> Saviq: but it has to be backed by something to have items.
[09:57] <Saviq> dednick, not really, it can be a random number generator ;)
[09:57] <Saviq> dednick, and building a QMap<QString, QVariant> out of all the roles through data() is a bad thing to do
[09:57] <Saviq> dednick, we just added the last paragraph to https://docs.google.com/a/canonical.com/document/d/1gd87Wo_CSB0DpFWLpTKIIXQfdmFncrq0PHSr9H2PTnk/edit btw
[09:58] <Saviq> dednick, that talks some about what you're asking
[10:18] <larsu> dednick: thanks!
[10:19] <larsu> dednick: ooh, this is quite signal happy... why are you emitting stateChanged() on rowsInserted/Removed?
[10:20] <dednick> larsu: yeah, signals everywhere. i guess it's been created that means the row is there.
[10:20] <dednick> larsu: in which case you can remove.
[10:20] <larsu> dednick: right
[10:21] <larsu> dednick: dataChanged() can happen when something other than the state changes, too
[10:21] <larsu> but I guess that's a premature optimization
[10:21] <dednick> larsu: yeah, i was going to streamline the roles later.
[10:22] <dednick> larsu: we have the index and the role we need, so can streamline it fairly well i think.
[10:22] <larsu> dednick: yep. But this is good enough for now (and I don't really have time to work on it today), so I'll just commit it for now. Thanks for the patch!
[10:22] <dednick> larsu: it was a bit of a crude impl. just needed it to work for now.
[10:23] <dednick> larsu: thanks.
[10:23] <larsu> yep, understood
[10:24] <dednick> larsu: what is the reasoning for loadExtendedAttributes?
[10:25] <dednick> larsu: can we not just fill ext with all the data the backend gives?
[10:25] <larsu> dednick: catching mismatches between what the ui requires and what the service provides early
[10:25] <dednick> larsu: i c.
[10:25] <dednick> larsu: its causing me much pain ;)
[10:25] <dednick> larsu: but no matter. i think i have a solution.
[10:26] <larsu> dednick: the other reason is that you can specify the type and it qmlifies it for you (only in the case of icons for now)
[10:26] <larsu> so you already get uris if you specify "icon"
[10:26] <larsu> dednick: is there anything I can change to make it easier?
[10:26] <dednick> larsu: ah yeah, i saw that... good stuff
[10:27] <larsu> dednick: pushed your patch
[10:29] <dednick> larsu: thanks. note for future. when we do the updateState, can we push a schema with that as well? i think qvariant rounds floats to ints if on an integer boundary. and we need it to convert correctly to gvariant.
[10:29] <dednick> larsu: at least something does that. not sure what.
[10:30] <dednick> larsu: it's causing type mismatch somewhere.
[10:31] <larsu> dednick: oh wow. Yeah, we could simply store the GVariant type information
[10:31] <tsdgeos> mzanetti: but the guy that wnts qt4 won't do much with it, no?
[10:32] <mzanetti> tsdgeos: ?
[10:33] <tsdgeos> mzanetti: don't think qt4 can put anything on screen in the phones since the qpa is not there
[10:33] <tsdgeos> and the phone doesn't have X
[10:33] <mzanetti> tsdgeos: oh... did he want to do something on the phone for it?
[10:33] <mzanetti> tsdgeos: I just read it as. using Qt5 for phone stuff and need Qt4 for something else
[10:33] <tsdgeos> well it was the ubuntu-phone ml
[10:34] <tsdgeos> ah
[10:34] <tsdgeos> you're probably right
[10:49] <Cimi> mzanetti, dammit I pushed on the trunk :-\ https://code.launchpad.net/~cimi/ubuntu-settings-components/calendar-newmodel/+merge/172598
[10:50] <mzanetti> Cimi: yeah, I've seen that. was wondering a bit...
[10:50] <mzanetti> thought maybe there is no autolanding set up for the settings-components yet
[10:51] <Cimi> no
[11:17] <nic-doffay> Saviq, ping
[11:23] <tsdgeos> nic-doffay: Saviq is busy at the IOM meeting, anything we can help with?
[11:31] <nic-doffay> tsdgeos, need to know who is handling design work for the sdk now that Calum's gone.
[11:41] <mzanetti> if someone has some time for a review: https://code.launchpad.net/~mzanetti/unity8/new-lockscreen-design/+merge/177555
[11:48]  * tsdgeos hates long lambdas
[11:49] <tsdgeos> inside long functions
[11:49] <tsdgeos> my eyes are not trained to see them :D
[11:49] <tsdgeos> http://paste.ubuntu.com/5928714/
[12:12] <Saviq> nic-doffay, you're asking about the option selector?
[12:12] <nic-doffay> Saviq, busy chatting about it now.
[12:12] <Saviq> nic-doffay, ok
[12:14] <dednick> larsu: how do i tell if a menu item is "activatable"?
[12:15] <dednick> larsu: eg the mute control doesnt have a type, but is togglable
[12:15] <larsu> dednick: if it is sensitive, it is activatable
[12:16] <dednick> larsu: everything is sensitive. even separators
[12:17] <larsu> dednick: if is sensitive and not a separator, it is activatable
[12:17] <larsu> :P
[12:17]  * larsu wonders if separators should not be sensible
[12:17] <larsu> in any case, gotta run. bbiab
[12:17] <dednick> larsu: lol. ok
[12:22] <sil2100> mhr3: ping
[12:37] <mhr3> sil2100, pong
[12:41] <sil2100> mhr3: about lucrene++, what do we need it for in main?
[12:42] <mhr3> sil2100, getting it first in universe would be enough for me :)
[12:42] <sil2100> mhr3: what will use it? ;)
[12:42] <mhr3> sil2100, but then the music and video scopes will
[12:43] <mhr3> the phone ones at least
[12:43] <sil2100> mhr3: ACK, then I'm on it
[12:43] <sil2100> Since I see the needs-packaging bug is abandoned ;/
[12:45] <mhr3> jamesh, could you point sil2100 to the latest branches ^?
[12:45] <mhr3> there were some fixes so it compiles with saucy libs
[12:45] <sil2100> mhr3, jamesh: isin't it https://github.com/luceneplusplus/LucenePlusPlus ?
[12:45] <sil2100> Ah
[12:45] <mhr3> not sure where those are
[12:46] <sil2100> hm, so we need some upstream changes for it to work with us?
[12:46] <sil2100> mhr3, jamesh: did you guys try getting those into upstream?
[12:47] <mhr3> sil2100, but maybe i'm wrong, lucene++ isn't the only component, maybe the fixes are specific to the other bits
[12:48] <sil2100> I will take care of it with pleasure, as I need karma for becoming a core dev ;p
[12:49] <sil2100> mhr3, jamesh: keep me informed, I'll start on the packaging now and we'll deal with the additional fixes later
[12:49] <mhr3> sil2100, thank you
[12:50] <sil2100> Better doing it ASAP before the FF
[12:50] <mhr3> indeed
[12:50] <mhr3> that's why i'm pinging about it :)
[12:55] <dandrader> mzanetti, ping
[12:56] <mzanetti> hi dandrader, wassup?
[12:56] <dandrader> hi
[12:56] <mhr3> sil2100, and having arm builds of it would be awesome
[12:56] <dandrader> mzanetti, do you know why I didn't hear back from jenkins after my latest update to https://code.launchpad.net/~dandrader/unity8/runningApps_lp1193419/+merge/175955
[12:56] <dandrader> ?
[12:56] <mzanetti> dandrader: I have noticed that the Dash tests sometimes hang and get killed only after an hour
[12:58] <mzanetti> dandrader: hmm... there isn't a job running tho...
[12:58] <dandrader> mzanetti, in this merge proposal I'm poking at the tst_Shell qmluitest. it's acting very weird in jenkins. seems like it start calling the test functions *before* the scene is fully loaded
[12:58] <dandrader> e.g.: some components are not found by findChild()
[12:58] <Saviq> mzanetti, https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-saucy/1446/?
[12:59] <dandrader> when the components are loaded you get a lot of warnings output to the console
[12:59] <dandrader> so you normally see this output during the initTestCase (or something like that) function
[12:59] <mzanetti> dandrader: are they loaded with a loader?
[12:59] <mzanetti> Saviq: what about this?
[12:59] <Saviq> mzanetti, those seem to be real failures
[12:59] <dandrader> but in jenkins you get that init output only on the first or second real test function
[13:00] <dandrader> that + the fact that some findChild() calls are failing point to my theory that jenkins is executing tests before the scene is fully loaded
[13:00] <dandrader> hence the latest workarounds I put in this MP
[13:02] <dandrader> mzanetti, let me check....
[13:04] <dandrader> mzanetti, yes. DashHome -> https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-saucy/832/testReport/junit/%28root%29/qmltestrunner/Shell__initTestCase/
[13:04] <mzanetti> dandrader: so you might want to add tryCompare(loader, "progress", 1) in initTestcase() ?
[13:05] <mzanetti> Saviq: do you know which upstream build it was?
[13:05] <dandrader> mzanetti, good idea.
[13:09] <Saviq> mzanetti, ah sorry - your "new lockscreen" branch
[13:10] <Saviq> mzanetti, forgot there's no mention of that in mediumtests runner
[13:12] <mzanetti> Saviq: hmpf... they pass locally
[13:14] <mzanetti> oh no... they dont
[13:14]  * mzanetti fixes
[13:14] <Saviq> mzanetti, ;)
[13:17] <mzanetti> Saviq: fixed. thanks for letting me know. I would have missed it
[13:17] <Saviq> mzanetti, cheers
[13:17] <Saviq> asac, unity8 is green today
[13:18] <asac> Saviq: rock on! :)
[13:18] <asac> lets hope for crash report support
[13:19] <Saviq> asac, indeed, since manta is showing *a* crash still - it might actually be the same I reported before
[13:20]  * sil2100 published unity8 in the morning
[13:25] <sil2100> mhr3: lucene++ sucks in this way that even though the git repo has CMake config files, the release tarballs don't
[13:25] <sil2100> It's like, a big WTF
[13:25] <sil2100> No new releases since 3 years ago
[13:29] <mhr3> sil2100, simple, package git snapshot :)
[13:45] <mzanetti> mterry: hey
[13:45] <mzanetti> mterry: did you test the ofono stuff already somehow?
[13:45] <mzanetti> mterry: I mean manually, not writing automated tests for it
[13:47] <mzanetti> mterry: my code should work in theory, but I'm having a hard time testing it on the phone
[13:48] <mterry> mzanetti, no.  I assumed libofono worked, and my plugin was such a thin wrapper, it didn't seem anything could go wrong
[13:48] <mzanetti> mterry: yeah... not saying your code wouldn't work... the thing is, apparently our ofono does not (yet) notice if you put in a sim card during runtime
[13:49] <mzanetti> mterry: and to test the startup scenario I need to install my branch into the system
[13:49] <mzanetti> thats why I ask - if you have some hints for triggering ofono or whatever...
[13:49] <mzanetti> but I'll figure it out
[13:50] <mzanetti> mterry: ah btw... you forgot to install the qmldir file. I fixed that in your branch. unfortunately I messed up the history :/
[13:50] <mzanetti> sorry about that
[13:50] <mterry> mzanetti, oh right, that's a separate CMake command now
[13:51] <mterry> mzanetti, it doesn't notice if you put a card in?  hmm...  awe made it sound like that stuff worked...  let me poke him
[13:52] <mzanetti> mterry: I'll push my stuff... might be buggy at some places because I couldn't fully test yet. but in theory it should support entering the pin at startup and also on the fly
[13:52] <mzanetti> mterry: pushed.
[13:53] <mterry> mzanetti, how does it handle on the fly?  Like, does it pop up a dialog?
[13:53] <Saviq> mzanetti, that looks like a valid failure as well for "new lockscreen" https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-saucy/840/?
[13:53] <seb128> mzanetti, mterry: do you guys have a custom made dialpad in your greeter?
[13:54] <mterry> seb128, yeah
[13:54] <seb128> I saw something looking like it in a merge request
[13:54] <seb128> mterry, do you know if there is any plan to have a proper shared widget for that? we need that in system settings as well
[13:54] <seb128> I'm pondering copying your meanwhile :p
[13:56] <mterry> seb128, ah interesting
[13:56] <mterry> seb128, it's a Qml file sitting on the disk...  Probably could be easily reused...
[13:57] <mterry> I don't know how hacky it is in the Qml universe to just point QML2_IMPORT_PATH at the unity dir and pull it in
[13:58] <seb128> Saviq, ^ how hackish is that?
[13:58] <seb128> mterry, I think I might just cp it, feels safer
[13:58] <seb128> especially if you guys don't promise stability for the behaviour/properties
[13:59]  * tsdgeos confused
[13:59] <tsdgeos>  error: format ‘%p’ expects argument of type ‘void*’, but argument 2 has type ‘mir::input::android::InputTargetEnumerator*’
[13:59] <tsdgeos> ?
[13:59] <mzanetti> seb128: I guess if we want a shared component we need to do it. the phone one will look slightly different.
[14:00] <Saviq> tsdgeos, ouch
[14:01] <mzanetti> seb128: the phone one will have a mailbox icon below the 1 and the letters below the other numbers etc. We don't need/want that for the PIN entry for example. but if you have the same requirements as I do, I'm open for reusing code
[14:01] <tsdgeos> Saviq: i added a nice (void*) cast to my printf :D
[14:01] <Saviq> mzanetti, seb128, mterry there's ubuntu-system-components that might be a possible place for it
[14:01] <seb128> mzanetti, is your design somewhere?
[14:01] <Saviq> mzanetti, seb128, mterry, or maybe it should actually be a theme delegate?
[14:02] <mzanetti> seb128: lp:amanzi-team/design
[14:02] <Saviq> (caveat: I don't know what I'm talking about)
[14:02] <mterry> Saviq, what is a theme delegate?
[14:02] <seb128> mzanetti, the ones we need are https://wiki.ubuntu.com/PhoneApp?action=AttachFile&do=get&target=phone-settings-call-diversion-number.png and https://wiki.ubuntu.com/Bluetooth?action=AttachFile&do=get&target=phone-bluetooth-pair.png
[14:02] <mzanetti> he doesn't know
[14:02] <mterry> Saviq, the theme says "draw a pin here" and the theme engine provides it?
[14:02] <mzanetti> seb128: this rather looks like a OSK plugin to me
[14:02] <mzanetti> seb128: a number-only OSK layout
[14:03] <seb128> mzanetti, is your different?
[14:03] <mzanetti> seb128: lemme upload a pic
[14:03] <Saviq> seb128, mterry, mzanetti +1 - it should be OSK
[14:03] <seb128> hum
[14:03] <mzanetti> seb128: this is ours: http://wstaw.org/m/2013/07/30/plasma-desktopkO1139.png
[14:04] <seb128> can the OSK be "embedded" in the app?
[14:04] <seb128> or do you mean it's like splitting screen in half
[14:04] <Saviq> seb128, why do you want it embedded?
[14:04] <seb128> where the bottom part is the osk?
[14:04] <mzanetti> seb128: I don't think so, but you can pop it up an lock it to open I think
[14:04] <mzanetti> the user won't see the difference
[14:04] <Saviq> seb128, see http://qt-project.org/doc/qt-5.0/qtqml/qml-qt.html#inputMethod-prop btw
[14:04] <Saviq> seb128, which is exposing the keyboard state and geometry to your app
[14:05] <seb128> Saviq, thanks
[14:05] <seb128> mzanetti, Saviq: right, I'm used to test on my desktop and not fully think "phone/full screen"
[14:05] <seb128> Saviq, mzanetti: thanks for the advices!
[14:05] <Saviq> seb128, on desktop nothing should happen, then, you just type it with your keyboard :)
[14:06] <seb128> well, I was shooting for having an UI with the pad displayed in the dialog and mouse clickable
[14:06] <seb128> but yeah, keyboard is good enough
[14:24] <sil2100> mhr3: dude, what the heck is wrong with this lucene package, it's building like 20 minutes already
[14:24] <sil2100> It's like a kernel god dammit
[14:24] <mhr3> sil2100, pfff, you'll be happy if it finishes in an hour :P
[14:24] <sil2100> Daaamn ;p
[14:25] <sil2100> I suppose this package cleans, does the laundry and walks the dogs for its user?
[14:25] <mhr3> sil2100, and makes sandwiches!
[14:25] <mhr3> but you need sudo for that
[14:26] <sil2100> ;)
[14:34]  * tsdgeos needs someone from mir
[14:34] <tsdgeos> is there a #ubuntu-mir ?
[14:35] <tsdgeos> yes there is
[14:53] <ritz__> hi, could anyone look up https://bugs.launchpad.net/indicator-session/+bug/1206231
[15:01] <tsdgeos> Saviq: ping
[15:01] <Saviq> tsdgeos, pong
[15:02] <tsdgeos> Saviq: i can give you a shell in which you can interact with the app you launched, but you can't go back :D
[15:02] <tsdgeos> which atm you can't go back anyway
[15:02] <tsdgeos> so it's a bit of an improvement
[15:02] <tsdgeos> not sure if enough :D
[15:02] <tsdgeos> it's basically a hack
[15:06] <Saviq> tsdgeos, can't go back meaning? if I open an app, I can't go back to shell any more?
[15:06] <Saviq> brb, need to reboot
[15:06] <tsdgeos> Saviq: yep, that
[15:16] <Saviq> tsdgeos, I'll wait for a better result ;)
[15:16] <tsdgeos> ok
[15:16] <dandrader> mzanetti, have you tried that trick of checking a Loader's progress before? from the documentation it seems it's about downloading the file from the network and not about instantiating components by parsing the file...
[15:17] <tsdgeos> Saviq: not sure i'll be able to produce that today
[15:17] <mzanetti> dandrader: i used it before, yes. might have been Loader.status == Loader.Ready
[15:17] <mzanetti> dandrader: or Loader.item !== undefined
[15:18] <mzanetti> dandrader: but there is a way to figure when its done
[15:18] <dandrader> "Note that if the source is a local file, the status will initially be Ready (or Error). While there will be no onStatusChanged signal in that case, the onLoaded will still be invoked."
[15:19] <dandrader> mzanetti,  "Loader.item !== undefined" sounds solid
[15:19] <mzanetti> dandrader: a waitForRendering(someItemContainingTheLoader) might do to
[15:19] <mzanetti> dandrader: if the file is always a local file
[15:19] <mzanetti> dandrader: but I guess in most cases that's safe to assume
[15:20] <dandrader> mzanetti,  where this waitForRendering comes from?
[15:20] <mzanetti> dandrader: I think from TestCase... tsdgeos digged it out at some point
[15:21] <tsdgeos> yep
[15:21] <dandrader> hmm
[15:21] <mzanetti> dandrader: anyways, check the lockscreen tests. there is a Loader which loads either the PIN or Passphrase lockscreen
[15:21] <mzanetti> dandrader: and the tests seem to work fine when using waitForRendering
[15:21] <dandrader> mzanetti, ok
[15:28] <tsdgeos> dandrader: you did the DDA thingie, right?
[15:29] <dandrader> tsdgeos, it depends. is there a problem with it?
[15:29] <tsdgeos> dandrader: no
[15:29] <dandrader> tsdgeos, ok, then yes, I did it :)
[15:30] <tsdgeos> dandrader: i just want to know if they define a width i can use to punch holes when using unity-mir
[15:30] <tsdgeos> i.e. the DDA of the bottombar for example
[15:30] <tsdgeos> has a height of a few pixels i can use?
[15:30] <dandrader> tsdgeos, didn't really get your question...
[15:31] <dandrader> tsdgeos, but the size of the DirectionDragArea is the area where touch events will be caught
[15:31] <tsdgeos> dandrader: ok, that's what i wanted to know
[15:31] <tsdgeos> tx
[15:32] <tsdgeos> dandrader: so basically we are "stealing" the DDA's sizes from the apps at the moment, right?
[15:32] <tsdgeos> s/sizes/areas
[15:32] <dandrader> tsdgeos, yes
[15:33] <tsdgeos> okidoki
[15:33] <dandrader> tsdgeos, although that "stealing" is done by another component
[15:34] <tsdgeos> by who?
[15:35] <dandrader> tsdgeos, because the DirectionalDragArea is just another component, like Flickable. It doesn't have those cross-app stealing powers
[15:35] <tsdgeos> ah
[15:35] <tsdgeos> sure
[15:35] <tsdgeos> well
[15:35]  * dandrader checks
[15:35] <tsdgeos> it does have for me
[15:35] <tsdgeos> since i'm unity-mir
[15:35] <tsdgeos> i'm all powerful
[15:35] <dandrader> tsdgeos, InputFilterArea is the one
[15:36] <mzanetti> guess who just successfully entered the SIM pin through the UI
[15:36] <dandrader> tsdgeos, but that "stealing" scheme is going away once we have a proper gesture canceling or accept/reject
[15:36] <dandrader> by gesture I mean simply a group of touch events from a given touch point)
[15:37] <tsdgeos> sure
[15:37] <tsdgeos> i'm just trying to get the unity-mir stuff to kind of work
[15:37] <tsdgeos> i'll let the smart stuff for when gerry is back :D
[15:37] <dandrader> mzanetti, congrats
[15:37] <mzanetti> dandrader: thanks :)
[15:37]  * mzanetti needs to clean up the room because that *might* get him into the Kyle Gass project
[15:46] <dandrader> mzanetti, what's the name of that suspect component again (the memory leak thing)
[15:46] <dandrader> in the ubuntu toolkit
[15:47] <dandrader> mzanetti, UbuntuShape?
[15:49] <mzanetti> dandrader: yeah, UbuntuShape had lots of bugs with leaking memory
[15:49] <Saviq> dandrader, mzanetti there's a rewrite in the works, btw
[15:49] <mzanetti> Saviq: yeah, still useful to know if its indeed that
[15:49] <Saviq> dandrader, try loicm to see if he has something you could use to investigate
[15:49] <Saviq> mzanetti, of course
[15:59] <tsdgeos> Saviq: ok so with lp:~aacid/unity-mir/improve_input_area_handling lp:~aacid/mir/hidden_surface_no_contains and lp:~aacid/unity8/unity8-integrate-mir-input-areas you should have a shell that is kind of usable, can launch apps, use them, switch them back with the left swipe (not sure if right swipe) works
[16:00] <tsdgeos> i know building 3 branches kind of sucks :D
[16:00] <Saviq> tsdgeos, you can push to unity-mir directly
[16:00] <Saviq> tsdgeos, and to unity8-integrate-mir
[16:01] <Saviq> tsdgeos, only the mir one needs to go through MR
[16:01] <tsdgeos> i know
[16:01] <Saviq> tsdgeos, and I'll trigger builds into https://launchpad.net/~phablet-team/+archive/mir/
[16:01] <tsdgeos> the unity-mir change should be ok, but still with gerry we said we would do MRs
[16:01] <tsdgeos> unity8-integrate-mir is a bit of a hack
[16:01] <tsdgeos> i mean it works better than now
[16:02] <tsdgeos> but may want gerry to give an "architecture" overview
[16:02] <tsdgeos> but if you want i can just push them
[16:02] <tsdgeos> and then when gerry is back we have a look
[16:02] <Saviq> tsdgeos, it's probably fine
[16:02] <Saviq> tsdgeos, let's talk tomorrow, have your afternoon
[16:02] <tsdgeos> Saviq: well, you need to show it tomorrow, no?
[16:02] <Saviq> tsdgeos, I'll try and try it out in the mean time
[16:02] <tsdgeos> what time?
[16:02] <Saviq> tsdgeos, tomorrow afternoon
[16:02] <tsdgeos> ok
[16:02] <Saviq> tsdgeos, 0200UTC
[16:03] <Saviq> pm
[16:03] <Saviq> so 1400UTC ;)
[16:03] <Saviq> sorry
[16:03] <tsdgeos> you probably don't need lp:~aacid/mir/hidden_surface_no_contains unless you want to use more than 1 app at the same time
[16:03] <Saviq> tsdgeos, yeah, let's see where we get tomorrow
[16:04] <Saviq> tsdgeos, I'll try and get the mir guys to review that in the mean time
[16:04] <tsdgeos> they seem to be on it
[16:04] <Saviq> ok cool
[16:04] <tsdgeos> at least alan_g gave a +1
[16:04] <tsdgeos> not sure if that measn it'll be merged or not :D
[16:05] <Saviq> tsdgeos, they'll probably wait for another +1
[16:06] <alan_g> tsdgeos: If no-one top-approves before my start of day tomorrow. I'll do it. (But other timezones ought to get a say.)
[16:06] <tsdgeos> sure
[16:06] <tsdgeos> no hurry :-)
[16:09]  * tsdgeos logs off for the day
[16:30] <pete-woods> dednick: hi
[16:30] <dednick> pete-woods: howdy
[16:31] <pete-woods> dednick: I'm just looking at unitymenumodel/qmenumodel - should I be able to export a menumodel using Qt with that?
[16:31] <pete-woods> or is it just for connecting to already exported gmenumodels?
[16:32] <dednick> pete-woods: it's for the frontend. needs an exported model.
[16:32] <pete-woods> dednick: so the only way to export a model at the moment is through the gmenumodel API?
[16:32] <dandrader> mzanetti, Saviq without UbuntuShape and memory still growing as usual
[16:33] <dandrader> FYI ^
[16:33] <Saviq> dandrader, thanks
[16:33] <dednick> pete-woods: as far as i know. larsu is gmenumodel qt king.
[16:34] <dednick> although i'm sure he wont appreciate me causing him more pings :)
[16:35] <pete-woods> that's fair enough :) thanks for the info!
[16:35] <dednick> pete-woods: i know there are vala bindings for menus, but i guess that just boils down to gmenumdel anyway. and don;t know if you would be interested in that
[16:42] <pete-woods> dednick: I was really looking to export a model model from a Qt application - sounds like qmenumodel isn't quite enough to do that
[16:44] <dednick> pete-woods: no. it's just a data model, doesnt build anything. You'll have to build it build & export gmenumodel.
[16:45] <dednick> *using gmenumodel
[17:02] <seb128> mhr3, hey
[17:03] <seb128> mhr3, did you see https://bugs.launchpad.net/ubuntu/+source/libunity/+bug/1201526 ? it seems to be a frequent issue
[17:10] <mhr3> seb128, thx, assigned to our python expert :)
[17:10] <seb128> mhr3, thanks
[20:16] <dednick> Saviq: ping
[20:17] <Saviq> dednick, man, sleep?
[20:17] <dednick> Saviq: you?
[20:17] <Saviq> dednick, or at least go away :)
[20:17] <Saviq> dednick, don't ask
[20:17] <Saviq> dednick, at least there's pizza and beer here ;)
[20:17] <dednick> Saviq: ahha. are you at IOM?
[20:17] <Saviq> dednick, yeah
[20:17] <dednick> Saviq: "i c"
[20:18] <dednick> Saviq: just wondering if you know if anything reacts to volume changes on the device at the moment.
[20:19] <Saviq> dednick, yeah, it should
[20:19] <Saviq> dednick, both buttons and sound indicator should work
[20:19] <dednick> Saviq: hm. interesting. maybe i need to flash my device. probably screwed things up with new indicators
[20:20] <dednick> Saviq: ok! thanks. have a good night :)