=== alan_g is now known as alan_g|afk
=== alan_g|afk is now known as alan_g
[08:14] <didrocks> hey sil2100, how are you?
[08:29] <sil2100> didrocks: hi! Sleepy ;)
[08:36] <sil2100> didrocks: I re-triggered all the stupid powerpc builds that failed
[08:36] <sil2100> ;/
[08:37] <didrocks> sil2100: do we know why? it seems that there is something that can't be installed (some arch:all, arch:any, but can't figure out what): https://launchpadlibrarian.net/140580074/buildlog_ubuntu-raring-powerpc.unity-lens-files_7.1.0daily13.05.24ubuntu.unity.next-0ubuntu1_FAILEDTOBUILD.txt.gz
[09:15] <sil2100> Wellark: ping ;)
[09:39] <sil2100> didrocks: I need to look into that again, since it happens too frequently
[09:40] <sil2100> And why only powerpc? Mystery
[09:40] <didrocks> yep :/
[09:44] <nic-doffay> Saviq, need your expertise for an issue.
[09:44] <Saviq> nic-doffay, hit me
[09:45] <nic-doffay> Saviq, bit of a complicated scenario.
[09:45] <nic-doffay> Saviq, https://code.launchpad.net/~unity-team/unity/infographics-with-lightdm
[09:45] <nic-doffay> there's the branch.
[09:45] <nic-doffay> If you look in Infographics.qml
[09:46] <nic-doffay> You'll see the onDataChanged signal and onDataAboutToChange signal.
[09:47] <nic-doffay> Saviq, let me know if you can't find it.
[09:47] <Saviq> nic-doffay, I'm there
[09:49] <nic-doffay> The current issue is that the onDataAboutToChange and onDataChanged signal are fired off too quickly.
[09:49] <nic-doffay> So the reverse animation affects the new set of data.
[09:49] <nic-doffay> (As does the reveal animation)
[09:50] <nic-doffay> You can run it and see what I mean (I've commented out the reveal animation to make it more obvious).
[09:50] <Saviq> nic-doffay, I do understand what you mean
[09:50] <Saviq> nic-doffay, you need to "cache" the old model before swapping it if the new one
[09:51] <Saviq> nic-doffay, pete-woods1 there's two possible solutions I can see
[09:51] <nic-doffay> Saviq, ok. Then perform the animation on the cached one.
[09:51] <Saviq> nic-doffay, pete-woods1, either expose both the "current" and "next" models
[09:52] <Saviq> nic-doffay, and then you switch the model after you've finished the reverse animation
[09:52] <Saviq> nic-doffay, and then start the reveal animation
[09:52] <Saviq> nic-doffay, pete-woods1, or you signal the "I'm ready to get the new model" after you've finished the reverse animation
[09:53] <Saviq> nic-doffay, and wait for the backend to tell you "the model has been updated" before starting the new animation
[09:53] <Saviq> s/new/reveal/
[09:53] <nic-doffay> Saviq, that's what I suggested, but pete-woods1 feels the backend should only communicate to the UI. I think that's a valid point too.
[09:53] <pete-woods1> what I said is I can't interrogate the UI's state
[09:54] <Saviq> nic-doffay, can't interrogate, that's fine
[09:54] <Saviq> nic-doffay, but you can _tell it_
[09:54] <Saviq> nic-doffay, via a signal / method exposed on the model or somewhere
[09:54] <Saviq> nic-doffay, that you're now ready to take the new data
[09:54] <Saviq> nic-doffay, pete-woods1, that approach seems potentially easier
[09:55] <nic-doffay> Saviq, yeah. Just a signal on the QML to fire's when the animation has stopped.
[09:55] <Saviq> nic-doffay, pete-woods1, but it might come with a delay between the reverse and reveal animations
[09:55] <Saviq> you have to check
[09:55] <nic-doffay> Saviq, what sort of delay are you thinking?
[09:55] <Saviq> nic-doffay, the time needed for the backend to replace the data
[09:56] <pete-woods1> and to transport it to the UI
[09:56] <pete-woods1> and potentially create new circles, etc
[09:56] <Saviq> pete-woods1, that would need to happen regardless of which mode we go for
[09:56] <pete-woods1> I think that's probably the best time for the delay, though
[09:56] <pete-woods1> as the thing should be invisible at that point
[09:56] <Saviq> pete-woods1, of course, but if you can prepare the model _while_ the reverse animation is happening
[09:57] <Saviq> pete-woods1, the delay could be lower
[09:57] <pete-woods1> true
[09:57] <Saviq> pete-woods1, but that's premature optimization
[09:57] <pete-woods1> indeedy
[09:58] <nic-doffay> Saviq, I can come up with something else in between the delay to make up for it.
[09:58] <Saviq> pete-woods1, nic-doffay, so I'd go for "backend says there's going to be a new data set soon; UI goes for reverse animation; UI signals that it's now ready for new data; backend fills the model with new data; backend signals that data is ready; UI goes for the reveal animation"
[09:58] <nic-doffay> Saviq, sounds good.
[09:58] <Saviq> and see how it does
[09:58] <nic-doffay> pete-woods1, on what object do you want the signals in the QML?
[10:02] <pete-woods1> nic-doffay: the signals would be present on the main infographic model
[10:02] <pete-woods1> you would be saying "ready to change" or something like that at the end of the fade out animation
[10:03] <pete-woods1> I'll add the signal to the model now, but it won't do anything, then at least you can get the UI to call it at the right time
[10:03] <pete-woods1> then I'll tweak the model so it behaves how you want
[10:04] <nic-doffay> pete-woods1, cool sounds good
[10:09]  * Saviq biab
[10:09] <nic-doffay> Saviq, ta for the suggestions.
[10:19] <sil2100> didrocks: hm, cyphermox already moved unity-gtk-module to the indicators stack, right?
[10:19] <sil2100> didrocks: do you know if he redeployed the unity stack after the change?
[10:20] <sil2100> didrocks: since the unity parameters in the generic check job seem to have unity-gtk-module in it
[10:20] <sil2100> Would suck to have unity-gtk-module released 2 times ;)
[10:21] <didrocks> sil2100: from jenkins, it seems he did that :)
[10:21] <didrocks> sil2100: I don't see the module, at least, he removed the job
[10:23] <sil2100> didrocks: then I wonder why ps-generic-* is still testpackages unity-autopilot unity-gtk-module-autopilot, and the invalid tests: unity unity-gtk-module unity-gtk-module-common libunity-gtk3-parser0
[10:23] <sil2100> Crazy stuff
[10:25] <didrocks> sil2100: yeah, weird (and no time to look at that TBH)
[10:27] <MacSlow> mzanetti, Saviq: I've fixed the issue from the comments on the MR (https://code.launchpad.net/~macslow/unity/phablet-snap-decision-action-expansion/+merge/165370/comments/366256), but can't get around a wait(100) for waiting on the collapse-animation to complete, thus the before-after height-test passes... any ideas? The expansion-animation doesn't seem to need this for its before-after test.
=== mmrazik is now known as mmrazik|lunch
[10:33] <mzanetti> MacSlow: hmm... not really sure what happens. but usually an animation animates some property and you should be able to use a tryCompare() to wait for that property to be finished animating
[10:33] <MacSlow> mzanetti, ok... trying tryCompare() again
[10:34] <mzanetti> MacSlow: otherwise, looking at the MR, seems there are a bit too many actionSpy.clear()s in it
[10:34] <mzanetti> MacSlow: rest looks quite ok to me
[10:40] <MacSlow> mzanetti, tryCompare() just sits there... that's not working
[10:41] <mzanetti> MacSlow: should I have a look at it or do you want to go with that wait(100)?
[10:41] <MacSlow> mzanetti, well I know a wait(100) will not pass the review :)
[10:41] <mzanetti> ok... let me check
=== MacSlow is now known as MacSlow|lunch
[11:08] <mzanetti> MacSlow|lunch: the tryCompare works for me. I've commented on the MR...
=== mzanetti is now known as mzanetti|lunch
[11:24] <Wellark> sil2100: pong
=== alan_g is now known as alan_g|lunch
=== mzanetti|lunch is now known as mzanetti
[12:10] <sil2100> Wellark: hi! Are you working on the HUD backend?
[12:16] <Saviq> mzanetti, I'm reviewing lp:~dandrader/unity/phablet_edgeDragInLauncher... I hope you'll simplify Launcher.qml a lot ;)
[12:17] <mzanetti> Saviq: yes. I expect the revealing and hiding to happen by daniel's code and all the rest will just go away
[12:17] <Saviq> mzanetti, the amount of states alone is scary
[12:17] <mzanetti> Saviq: no more states (maybe just a closed, opened and hint)
[12:18] <mzanetti> at max
[12:18] <Saviq> mzanetti, cool :)
[12:19] <mzanetti> anyone knows whats the state of mobile data connection is? friends of mine are just waiting for that before flashing their phones :D
[12:22] <Saviq> rsalveti, ^?
=== mmrazik|lunch is now known as mmrazik
=== _salem is now known as salem_
[12:33] <didrocks> sil2100: should you restart the apps stack?
[12:34] <sil2100> didrocks: will do, just checking the exact failure
[12:34] <sil2100> Eh
[12:35] <didrocks> thanks!
[12:38] <Saviq> mzanetti, when working on the N10 greeter, I recommend switching to adb over TCP - it doesn't drop the connection when you lock the screen - so it doesn't destroy tablet-services
[12:39] <Saviq> mzanetti, I'll have a small tweak to run_on_device to help with that
[12:39] <mzanetti> Saviq: afaik our run_on_device always works through adb forwarding
[12:39] <Saviq> mzanetti, that's not even about that
[12:39] <paulliu> Saviq: https://code.launchpad.net/~paulliu/unity/i18n/+merge/165160'
[12:40] <paulliu> Saviq: https://code.launchpad.net/~paulliu/unity/i18n/+merge/165160
[12:40] <Saviq> mzanetti, the important thing is that adb itself goes through TCP and not USB
[12:40] <mzanetti> Saviq: oh, interesting
[12:40] <paulliu> Saviq: BTW, the changes to debian/* is caused by wrap-and-sort. Do we want that in a seperated branch?
[12:40] <Saviq> paulliu, yes please
[12:40] <paulliu> Saviq: ok.
[12:41] <Saviq> mzanetti, whether it does forwarding or not is a different issue (and only an issue when you have two devices at the same time - and that I want to enable in run_on_device)
[12:41] <paulliu> Saviq: Please review that branch. And I'll prepare a wrap-and-sort for debian/* later.
[12:41] <Saviq> mzanetti, I can now go run_on_device for both phone and tablet at the same time
[12:42] <mzanetti> Saviq: cool. iirc there is some command where you can register to the HUP signal. We might be able to use that too so when you unplug during a run_on_device it still restores the *-services file
[12:42] <Saviq> mzanetti, right
[12:51] <Saviq> mzanetti, https://code.launchpad.net/~saviq/unity/phablet.run-on-device-remote/+merge/165606
[12:52] <Saviq> mzanetti, with that you can export TARGET_IP and TARGET_SSH_PORT in your shell for run_on_device to go over TCP
[12:52] <Saviq> mzanetti, and http://stackoverflow.com/questions/2604727/how-can-i-connect-to-android-with-adb-over-tcp for enabling adb over tcp
[12:53] <Saviq> mzanetti, if you want it to persist across reboots (and even flashes, it seems), `adb setprop persist.adb.tcp.port 5555`
=== MacSlow|lunch is now known as MacSlow
[12:54] <Saviq> mzanetti, I also recommend installing ninja-build on the device to improve build time (especially no-build-needed time)
=== alan_g|lunch is now known as alan_g
[12:55] <mzanetti> Saviq: so we should probably pack that into build -s
[12:55] <Saviq> mzanetti, indeed, actually let me drop that into the same branch
[12:57] <Saviq> mzanetti, actually not for build -s as that would mean people have to s/make/ninja/ in their minds
[12:57] <mzanetti> isn't that transparent?
[12:57] <Saviq> mzanetti, not if you `make test` or similar
[13:02] <Saviq> paulliu, the pl.po file got wrong encoding
[13:02] <mzanetti> Saviq: TARGET_IP=${TARGET_IP-127.0.0.1}
[13:02] <mzanetti> Saviq: haven't seen that notation before. what exactly does that do?
[13:02] <Saviq> mzanetti, that's the default value if unset
[13:02] <Saviq> mzanetti, so if $TARGET_IP is unset (not empty, but _unset_)
[13:03] <Saviq> mzanetti, it will get set to 127.0.0.1
[13:03] <mzanetti> cool. useful stuff :)
[13:03] <Saviq> paulliu, `wget -O po/pl.po http://pastebin.ubuntu.com/5694011/plain/` should help
[13:04] <Saviq> ugh
[13:04] <Saviq> if only pastebin wasn't stupid
[13:04] <Saviq> and wouldn't require SSO for plaintext download <facepalm />
[13:05] <paulliu> Saviq: ok..wait
[13:05] <Saviq> paulliu, will email you the file in a sec
[13:08] <Saviq> paulliu, you've got it in email, should be fine if you save it as is
[13:08] <paulliu> ok
[13:09] <Saviq> paulliu, "66	+ * wrap-and-sort the debian/* files." is still there in the changelog
[13:12] <paulliu> Saviq: ok. I'll remove it.
[13:17] <Saviq> paulliu, also, http://pastebin.ubuntu.com/5696932/ happens
[13:18] <Saviq> paulliu, you're calling the bindTextDomain too quickly
[13:20] <paulliu> Saviq: ah.. that's it.
[13:20] <dandrader> mzanetti, my Launcher modifications have landed. You can now rebase and propose yours
[13:20] <paulliu> Saviq: Let me fix it.
[13:21] <mzanetti> dandrader: thanks
[13:23] <Saviq> paulliu, do you think it would be possible to make it work without "make install"?
[13:23] <Saviq> paulliu, currently we need to make install just to make gettext pick the locales up from the installation dir
[13:23] <rsalveti> mzanetti: Saviq: we were able to do our first 3g data connection yesterday, should be landing next week
[13:23] <Saviq> rsalveti, awesome :)
[13:25] <mzanetti> rsalveti: \o/
[13:25] <Saviq> paulliu, and if you actually run from builddir/install (LD_LIBRARY_PATH=../unity_build/build/lib ./builddir/install/bin/qml-phone-shell) it won't pick the translations up, 'cause isRunningInstalled() is true in that case
[13:25] <Saviq> paulliu, isRunningInstalled() return true when running from CMAKE_INSTALL_PREFIX
[13:27] <paulliu> Saviq: yeah..let me see if I can fix that. Because we are using the default cmake gettext support. The mo files are only put into correct dir structure on install.
[13:27] <Saviq> paulliu, yeah, let's leave it for now
[13:28] <Saviq> paulliu, we'll just note that you need to `make install` before the translations get picked up for now
[13:28] <Saviq> paulliu, and later we'll look for a solution for that
[13:28] <paulliu> Saviq: ok.
[13:29] <Saviq> paulliu, you should update the .pot and .po now that you've added more translatable strings ;)
[13:29] <paulliu> Saviq: yes..
[13:29] <paulliu> Saviq: I'll add notes and refresh the pot/po files together. wait.
[13:30] <Saviq> paulliu, I'll send you an updated pl.po in a sec
[13:34] <mzanetti> dandrader: d'oh... the merge is conflicting quite a lot already
[13:35]  * dandrader is glad he got to merge his work first :)
[13:35] <dandrader> mzanetti, http://www.nelson-haha.com/
[13:36] <Saviq> paulliu, sent you an update
[13:36] <paulliu> Saviq: ok.
[13:36] <mzanetti> dandrader: not funny
[13:37] <mzanetti> :P
[13:37] <mzanetti> dandrader: http://nooooooooooooooo.com/
[13:38] <dandrader> :)
[13:38] <cyphermox> sil2100: didrocks: I couldn't redeploy unity, it was running at the time
[13:44] <didrocks> cyphermox: ok, mind doing it now?
[13:44] <didrocks> sil2100: don't touch the apps stack
[13:44] <sil2100> o>
[13:44] <Saviq> dednick_, nic-doffay standup?
[13:45] <sil2100> didrocks: sucks, one test failed in apps
[13:46] <cyphermox> didrocks: that's what I'm doing
[13:46] <didrocks> sil2100: yeah, we're trying otto on it
[13:46] <didrocks> cyphermox: thanks!
[13:48] <cyphermox> didrocks: done.
[13:48] <cyphermox> should I rerun unity as well?
[13:49] <cyphermox> I'd double-check indicators too, to pick up from tomorrow
[13:52] <cyphermox> I meant yesterday of course
[13:52] <mterry> mzanetti, regarding my ColorImageProvider, one problem with your suggestion is that we use CrossFadeImage for the wallpaper.  I suppose I could add color support directly to that Component, but I was leery of modifying those
[13:53] <mzanetti> mterry: ohhh... right... didn't think of that
[13:53] <mzanetti> mterry: hmm... the ColorImageProvider still seems funky to me :D
[13:54] <mzanetti> mterry: FYI: the CrossfadeImage is only used in the greeter. so breaking it just breaks our stuff
[13:54] <mzanetti> Saviq: whats your opinion?
[13:55] <mterry> Saviq, this is in reference to https://code.launchpad.net/~mterry/unity/phablet-greeter-features/+merge/165479
[13:55] <mzanetti> Saviq: mterry created a ColorImageProvider which just paints a rectangle with the given color. I said he should use regular Rectangles in QML for that
[13:55] <mterry> Saviq, and it's ColorImageProvider
[13:55] <Saviq> mzanetti, mterry yeah I know what's this about
[13:55] <mterry> :)
[13:56] <Saviq> mterry it does feel like it'd be slower than a Rectangle
[13:56] <Saviq> mterry, so yeah, I'd probably go for tweaking CrossFadeImage
[13:56] <mterry> OK!
[13:57] <Saviq> mterry, so that it would support "fade to color" apart from "fade to another image"
[13:57] <Saviq> mterry, I think it makes sense to be there
[13:57] <Saviq> mzanetti, ^
[13:57] <mzanetti> yep
[13:57] <mzanetti> I agree
[13:59] <paulliu> Saviq: Just pushed.. https://code.launchpad.net/~paulliu/unity/i18n/+merge/165160
[14:00] <Saviq> paulliu, cheers
[14:00] <mzanetti> dandrader: can you please shortly explain what your change actually changes?
[14:01] <mzanetti> dandrader: should there be a change in behavior or should I not notice anything different?
[14:01] <dandrader> mzanetti, 1-  replaced DraggingArea with DirectionalDragArea
[14:01] <mzanetti> ok, seen that
[14:02] <dandrader> mzanetti, 2- removed the behavior where you can drag and already launch an application once you release
[14:02] <mzanetti> dandrader: ok. that was removed in my branch too
[14:02] <dandrader> mzanetti, so you no longer see that toll-tip balloon
[14:02] <mzanetti> ah... you deleted the LauncherLabel.qml?
[14:03] <mzanetti> because that was a bit of a weird conflict
[14:03] <dandrader> mzanetti, yes
[14:03] <dandrader> mzanetti, as it's no longer used
[14:03] <mzanetti> ok... explains things
[14:03] <mzanetti> dandrader: I think we still need it later.. anyways. no problem
[14:03] <dandrader> mzanetti, that was my initial thought as well
[14:04] <mzanetti> dandrader: it will change a lot... I agree. so probably just deleting current version is the most sensible thing... I agree
[14:04] <dandrader> mzanetti, well, it's still there in history :)
[14:06] <mzanetti> ok... so as of now Launcher.qml is my domain. any confllicting changes will be overwritten :D
=== mmrazik is now known as mmrazik|afk
[14:07] <mzanetti> Saviq: ah... forgot to mention in the standup: before you use time to find the cause - I did it already: https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1183727
[14:07] <ubot5> Launchpad bug 1183727 in Ubuntu UI Toolkit "[UbuntuShape] using an image with properties asynchronous and sourceSize set causes artifacts when resizing" [High,New]
[14:12] <Saviq> mzanetti, not seeing in the shell ;)
[14:13] <mzanetti> Saviq: no?
[14:13] <Saviq> kgunn, here's the CODING update https://code.launchpad.net/~saviq/unity/phablet.run-on-device-remote/+merge/165606
[14:13] <Saviq> mzanetti, what exactly should I be looking at / doing?
[14:13] <Saviq> mzanetti, ah or do you mean when I resize the window on my desktop?
[14:13] <kgunn> Saviq: cool, i'll take care
[14:13] <mzanetti> Saviq: yes
[14:13] <Saviq> mzanetti, yeah, seeing it
[14:14] <Saviq> mzanetti, I broke the autolanding in here https://code.launchpad.net/~saviq/unity/phablet.run-on-device-remote/+merge/165606
[14:15] <mzanetti> naughty boy
[14:17] <mzanetti> Saviq: is that CODING file generated to html or anything?
[14:18] <Saviq> mzanetti, kgunn does the generating to html ;)
[14:18] <Saviq> mzanetti, but it's ~ ReST
[14:18] <Saviq> or whatever the shortcut is for restructured text
[14:18] <mzanetti> Saviq: "TL;DR" ??
[14:18] <Saviq> mzanetti, Too Long; Didn't Read
[14:18] <Saviq> mzanetti, your geek foo is not good
[14:19] <mzanetti> hehe
[14:19] <mzanetti> Saviq: the geek-foo dict is TL:DR
[14:19] <Saviq> mzanetti, http://www.urbandictionary.com/define.php?term=tl%3Bdr
[14:19] <Saviq> :P
[14:20] <Saviq> mzanetti, http://en.wikipedia.org/wiki/Wikipedia:Too_long;_didn%27t_read
[14:20] <Saviq> mzanetti, http://en.wiktionary.org/wiki/TL;DR
[14:20] <Saviq> mzanetti, really? :P
[14:20] <kgunn> mzanetti: i had to look it up the other day
[14:20] <Saviq> kgunn, you're excused, you're a manager ;P
[14:20] <kgunn> :))
[14:21] <mzanetti> you know... I get that in a chat and look it up. I see that in a file in the code tree and think this will generate some fancy html tag in the docs
[14:23] <nic-doffay> mzanetti, looking at your branch atm.
[14:24] <nic-doffay> Must I uncomment everything that's commented?
[14:24] <nic-doffay> in Lockscreen.
[14:24] <mzanetti> nic-doffay: no...
[14:24] <nic-doffay> mzanetti, what needs to be uncommented?
[14:24] <mzanetti> nic-doffay: there should be your shader somewhere... use the one in Shell.qml
[14:24] <nic-doffay> mzanetti, getting rid of that there for now.
[14:24] <nic-doffay> Adding it somewhere else.
=== alan_g is now known as alan_g|tea
[14:24] <nic-doffay> mainly wondering about this mzanetti layer.enabled: root.required && ! greeter.shown && shell.applicationManager.mainStageFocusedApplication
[14:25] <mzanetti> nic-doffay: let me check... I think I pused some stuff today morning that removes all the shaders
=== alan_g|tea is now known as alan_g
[14:40] <Saviq> dandrader, re autopilot - sounds like that's expected? a Pointer shouldn't do Touch
[14:40] <Saviq> dandrader, so it probably sent mouse events anyway?
[14:40] <dandrader> Saviq, "The Pointer class is a wrapper that unifies the API of the Mouse and Touch classes, which can be helpful if you want to write a test that can use either a mouse of a touch device."
[14:41] <Saviq> dandrader, bad naming it seems ;)
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
[15:13] <nic-doffay> bregma, any idea which version of unity will work with Nux 4.0?
[15:14] <bregma> nic-doffay, Nux 4.0 is the current version of Nux (well, 4.0.2), which is trunk Uniy (Unity 7)
[15:14] <nic-doffay> bregma, ok ta
=== salem_ is now known as _salem
[16:04] <sil2100> Saviq: ping
[16:04] <Saviq> sil2100, pong
=== _salem is now known as salem_
[16:29] <Saviq> dandrader, we were 2 tests away from 300 and we're back to 296 because of your merge :P
[16:29] <Saviq> dandrader, not nice, not nice at all!
[16:30] <dandrader> Saviq, the Launcher change? yeah :)
[16:32] <mzanetti> dandrader: hey. I'm having a strange issue with mouse events using the DirectionalDraggingArea. do you have a minute?
[16:32] <dandrader> mzanetti, yes
[16:33] <mzanetti> dandrader: I have a draggingarea and on top of it the launcher now
[16:33] <mzanetti> dandrader: that works quite well most of the time
[16:34] <mzanetti> dandrader: but sometimes, even tho I click on the launcher, the DirectionalDraggingArea underneath recognizes some touches
[16:34] <mzanetti> dandrader: status goes to Undecided and distanceChanged is emitted
[16:35] <mzanetti> dandrader: but the launchers flickable should handle it of course which is on top of the DraggingArea
[16:36] <mzanetti> could you think of something causing this?
[16:36] <dandrader> mzanetti, yes
[16:37] <dandrader> mzanetti, a touch event is sent first. it doesn't get handled by anyone Qt synthesizes an equivalent mouse event and sends it
[16:37] <dandrader> s/it doesn't/if it doesn't
[16:37] <dandrader> DraggingArea handles mouse events but DirectionalDragArea handles touch events
[16:37] <mzanetti> dandrader: oh. I might have been unclear. This is on the desktop. so I suppose we only have mouse clicks
[16:38] <dandrader> mzanetti, no, mouse events are converted to touch events by MouseTouchAdaptor
[16:38] <dandrader> mzanetti, so that we have the same code path as if we were running on the device
[16:38] <mzanetti> dandrader: ah, ok. makes sense
[16:39] <dandrader> mzanetti, try it with ./run --nomousetouch
[16:39] <mzanetti> dandrader: so, still it works most of the time. then I flick the launcher up and down a couple of times and suddendly the DirectionalDraggingArea gets the events
[16:39] <dandrader> DirectionalDragAreas won't work though...
[16:41] <dandrader> mzanetti, you could add some qDebugs() here and there to confirm my theory
[16:42] <mzanetti> dandrader: sure
[16:42] <mzanetti> but I don't really see why that would cause this behavior
[16:43] <dandrader> mzanetti, or using something that handles touches instead of a DraggingArea, but I'm not sure if it would be quick to try it out
=== salem_ is now known as _salem
[16:48] <mterry> mzanetti, I updated the branch, btw
[16:48] <mzanetti> mterry: ok. I'll review soon
[16:49] <mterry> mzanetti, I'd be happy to help talk you through changes you'll need for the PIN stuff today?  unless you're close to EOD
[16:52] <mzanetti> mterry: hmm... actually I am. Would like to finish that current task I'm on. But after the review today I have some idea on what to do next. will probably ask some smaller questions on monday
=== _salem is now known as salem_
[16:53] <mterry> mzanetti, OK.  Monday is a national holiday in US.  But I'll try to idle on IRC and check it now and then
[16:53] <mterry> mzanetti, but bottom line is that all the current PAM interaction is inside LoginList.qml, which isn't even used in phone mode
[16:53] <didrocks> sil2100: around?
[16:54] <mterry> mzanetti, so you'll have to write the PAM interaction in phone mode.  But you should be able to ape what's in LoginList
[16:54] <mzanetti> mterry: yes. my branch uses the singleton from within a new qml file (Lockscreen.qml)
[16:54] <mzanetti> mterry: yes. thats what I thought. great
[16:54] <mterry> mzanetti, OK.  My new branch exercises PAM workflows pretty well, so you should be able to see examples for whatever you need
=== dandrader is now known as dandrader|lunch
[16:55] <mterry> mzanetti, there are features in PAM that you may decide not to support this first go-through.  For example, info messages...  Not sure if the design mockups took such things into account
[16:56] <mzanetti> mterry: ah.. what I didn't see yet. is there a nice way to fire the showPrompt signal manually for testing already?
[16:56] <sil2100> didrocks: yep
[16:56] <sil2100> didrocks: what's up? :)
[16:57] <mterry> mzanetti, that's done inside the mock liblightdm object, triggered from an authenticate() call usually
[16:57] <mzanetti> mterry: no. I don't think there are info messages. at least not in the current designs
[16:57] <mterry> mzanetti, (well, there could be info messages from PAM, but we don't have a place to show them -- unlikely on our phone though)
[16:57] <mterry> mzanetti, see tests/mocks/LightDM/full/GreeterPrivate.cpp for examples of showPrompt
[16:58] <didrocks> sil2100: did you get in touch with osomon about the webbrowser failures?
[16:58] <mzanetti> mterry: ok. sounds good. I think I'll figure the rest
[16:58] <mzanetti> thanks a lot
[16:58] <mterry> mzanetti, sure, and like I said, I'll try to idle on IRC on Monday
[16:58] <mterry> May end up doing some work that day after all
[16:59] <mzanetti> mterry: I'll try to keep it to a minimum
[16:59] <mterry> mzanetti, have a good day!  will stop pinging you so you can go  :)
[17:00] <mzanetti> mterry: thanks. have a nice weekend!
[17:00] <nic-doffay> Enjoy the weekend everyone!
[17:02] <sil2100> didrocks: got disconnected from the internet...
[17:02] <didrocks> 18:58:09    didrocks | sil2100: did you get in touch with osomon about the webbrowser failures?
[17:03] <sil2100> didrocks: yes, we're chatting this very moment
[17:03] <didrocks> sil2100: excellent! :)
[17:03] <didrocks> thanks :)
[17:05] <bschaefer> sil2100, hey, also I got around the ABI for nux/2.0 (with help from bregma)
[17:05] <bschaefer> ABI break
[17:05] <sil2100> !
[17:05] <sil2100> bschaefer: oh!
[17:05] <bschaefer> sil2100, using a union :)
[17:05] <sil2100> bschaefer: since I poked the SRU team with a question about the ABI breakage, but no answer yet
[17:05] <bschaefer> sil2100, well now no worries! Thanks for poking them!
[17:06] <sil2100> Colin probably is busy
[17:06] <bschaefer> sil2100, but when the time comes to actually SRU there is a nux and unity branch that need to go in at the same time
=== alan_g is now known as alan_g|EOW
[17:06]  * bschaefer just wants to give enough of a heads up
[17:08] <bschaefer> but really, the nux branch doesn't really depend on the unity one...its just the unity one enables XIM support ;0
[17:08] <bschaefer> :)*
[17:09] <sil2100> ;)
[17:09] <sil2100> Awesome! It would be great to get that to 2.0
[17:10] <bschaefer> yup! I've a ppa, that i need to actual fix for when you don't have an IM active
[17:13] <sil2100> I'll be testing that on my old laptop on Monday then ;)
[17:14] <sil2100> But for now, I disappear
[17:14] <sil2100> See you around!
[17:14] <bschaefer> sil2100, cya!
=== dandrader|lunch is now known as dandrader
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== dandrader_ is now known as dandrader
=== salem_ is now known as _salem