[07:05] can i chat now? [09:43] what is the cross-compilation safe way of querying QT_INSTALL_QML path within cmake? [09:43] i have seen scripts calling qmake -query QT_INSTALL_QML? But that seems to fail in sbuild [09:53] oh ok Saviq already reported that [10:01] boneheads /o\ [10:24] anpok, yeah, the "safe" way is ${CMAKE_INSTALL_LIBDIR}/qt5/qml [10:29] AlbertA, could you please confirm in bug #1364453 what needs to happen [10:29] bug 1364453 in unity8 (Ubuntu) "Brightness setting does not persist across reboots" [High,Confirmed] https://launchpad.net/bugs/1364453 [10:41] Saviq: thx works [11:01] Buenas === MacSlow is now known as MacSlow|lunch === _salem is now known as salem_ === ubot5` is now known as ubot5 === MacSlow|lunch is now known as MacSlow [13:05] dednick, I wonder how come this wasn't crashing http://paste.ubuntu.com/8318782/ As was doing some qtmir changes this test was crashing and I did this change to fix it. [13:19] Actual (): USD0.99 [13:19] Expected (): 0.99USD [13:19] what do I set to fix that test? [13:24] greyback, LC_ALL=C [13:24] Saviq: I guessed that, thanks [13:25] just wanted confirmation while I waited :) [13:48] dandrader: erm. [13:49] dandrader: i guess the memory was still valid [13:50] dandrader: were you doing test in a debug build maybe? [13:51] dednick, yeah. maybe debug builds clear out freed memory right away [13:51] but release ones don't just bother (aka optimization) [13:52] *just don't [13:52] dandrader: ya. probably [13:57] popey: hey, so these are both yours...kinda feels like a dup...wonder if there's a slight nuance diff i'm missing (before i dup) [13:57] bug 1355422 [13:57] bug 1355422 in unity8 (Ubuntu) "[notifications] Can't dismiss notification bubbles" [High,In progress] https://launchpad.net/bugs/1355422 [13:58] bug 1334855 [13:58] bug 1334855 in Ubuntu UX "[design] Can't use toolbar while notifications on screen" [Undecided,New] https://launchpad.net/bugs/1334855 [13:58] yeah, they're same [13:59] i expect i forgot i filed one [13:59] yeah, 2 months between them, i certainly forgot ☻ [13:59] feel free to dupe them. [14:02] karni, https://bugs.launchpad.net/ubuntu/+source/unity-scopes-api/+bug/1368243/comments/2 [14:02] Ubuntu bug 1368243 in unity-scopes-api (Ubuntu) "Scope consistently causes scope runner crash" [Undecided,New] [14:03] Saviq: yes [14:06] Saviq: I'm supposed to run this on the device, or can I adb pull the log and run it on it? [14:06] on my PC [14:06] karni, device [14:06] karni, although at this point (I assume it's uploaded to errors.u.c it already has all the data) [14:07] there's no .uploaded file yet [14:07] karni, enough if there's an .upload one [14:07] karni, in general if you have a .crash file, use apport-cli to file it to LP [14:07] not either [14:07] karni, then yeah, on device [14:07] ok [14:07] karni, 'cause the .crash doesn't have info from the device yet [14:10] Saviq: Can I force the upload of the crash files? I'm reading apport-cli and apport-collect manual, and I've got other important work to do as well :( [14:10] I don't know what's the package name of scope runner [14:10] and apport-collect won't just take the crash file [14:10] karni, just apport-cli /path/to/crash [14:11] karni, let me know the bug number and I'll dupe as needed (you'll have to subscribe me 'cause bug will be private initially) [14:11] Saviq: https://bugs.launchpad.net/ubuntu/+source/unity-scopes-api/+bug/1368243/comments/3 [14:11] Ubuntu bug 1368243 in unity-scopes-api (Ubuntu) "Scope consistently causes scope runner crash" [Undecided,New] [14:12] karni, you can remove the "Reason" line from the .crash file [14:12] karni, you should be able to upload then [14:13] Saviq: the crash file does not contain a "Reason" word [14:13] karni, looks like the crash collection didn't work then [14:13] karni, steps to repro would be great (or removing the .crash and getting it to crash again, hoping the core will be good) [14:14] Saviq: repro is very simple. fresh flash (as of today), and open Photos scope [14:14] I'll include that in the report [14:14] karni, k [14:15] you guys know qml right? do you see anything wrong in http://paste.ubuntu.com/8319172/ [14:15] taht's driving me crazy [14:15] why isn't a text entry widget in a mainview with nothing else getting the keyboard focus by default, even with "focus: true" set [14:15] seb128, because you don't have a FocusScope with focus: true [14:16] Saviq, I though the scope was useful when you had groups of widgets [14:16] seb128, you need at least one, but in any case I'd recommend Component.onCompleted: forceActiveFocus() [14:18] Saviq, thanks, I guess that works, but it still seems qml is being overly complex there [14:18] those sort of things should just work :/ [14:19] seb128, yeah, but setting focus: true without a FocusScope doesn't do much [14:20] Saviq, the concept of focusscope is not easy to grasp, at least to me [14:20] on a normal column layout, there should be one scope and whatever widget has focus: true should get the focus [14:20] seb128, http://qt-project.org/doc/qt-5/qtquick-input-focus.html [14:20] without needing of magic [14:20] Saviq, I read that in the past, I guess I need to read it again [14:21] that's the sort of things that seem to just work in other toolkit, I wonder why it doesn't in qt :/ [14:21] seb128, within a FocusScope there's a chain/hierarchy of items, only one on each hierarchy level can have focus: true [14:21] seb128, that's basically a "cache" of focus [14:21] seb128, meaning that when the FocusScope gets focus, the last child to have focus: true gains activeFocus [14:22] Saviq, well, in my example there is nothing else that could get focus [14:22] seb128, this way you can move focus between FocusScopes while maintaining the focus chain within them [14:22] well I can change the pastbin to MainView { TextInput { }} [14:22] seb128, but only FocusScope handles these [14:22] * Saviq has no idea how MainView deals with that [14:22] Saviq, I appreciate it allows for complex scenarios to work [14:23] but it makes simple cases not work [14:23] like one widget on a page [14:23] and focus: true does nothing [14:23] I'm sure I'm not the only appdev to struggle with that ;-) [14:23] Saviq, thanks for the help/explanations! [14:24] Saviq, also on the same example, clicking on the button unfocus the entry, is that normal or a bug? [14:24] http://qt-project.org/doc/qt-5/qml-qtquick-controls-button.html states [14:24] "This property specifies whether the button should gain active focus when pressed. [14:24] The default value is false. [14:24] " [14:25] seb128, you most probably need to set focus: true on the MainView, too [14:25] setting that property to false works [14:25] so I guess the "default value is false" has an iossue [14:25] Saviq, oh, that works indeed ;-) [14:26] seb128, wonder if MainView is a FocusScope actually === shiznix_ is now known as shiznix [14:49] Cimi: hey. can you look over the changes i've made to https://code.launchpad.net/~nick-dedekind/ubuntu-settings-components/indicator-polishing/+merge/229083 since you approved? [14:49] dednick, why are you not in the hangout? :) [14:50] Cimi: i am! [14:55] seb128: with the datetime sync issue in u8 indicators, how long does it take to resync once the screen is back on? [15:03] dednick, under a minute [15:03] dednick, it looks like it doesn't get the update until it changes again [15:04] Saviq: hm. [15:04] dednick, but folks confirmed that if they dbus-query it, it's correct there [15:04] dednick, yeah, less than a minute usually [15:04] but it doesn't seem to be on minute changes [15:05] seb128: after the dbus query does the indicator ui sync? or still wrong for a bit? [15:33] seb128: you see the datetime thing on krillin? [15:33] dednick, yes [15:33] dednick, that's the device I'm testing on [15:33] seb128: can't seem to get it to fail on mako [15:33] seb128: will try on krillin [15:33] thanks [15:33] how much did you try? [15:33] it's not consistently happening [15:33] but I can see it several time a day [15:34] 2 or 3 times now. bit painfull waiting constantly :) === dandrader is now known as dandrader|afk [15:35] well, I don't think waiting/trying after a few minutes is going to work [15:35] though it might, who knows [15:35] dednick, you did disconnect it from usb did you? [15:35] Saviq: ya [15:35] typically I pick my krillin from my pocket after an hour not using it, to look at the time [15:36] seb128: my last try was about 20 minutes, but no sync issue i could see [15:36] but if it's random... [15:36] yeah [15:36] what sort of info would you need when it happens? [15:36] the dbus call to the indicator display the right time [15:36] the greeter/lock and panel are off though [15:38] seb128: doesn't it sync straight after you reconnect usb? [15:39] dednick, not sure, going to tell you next time [15:39] seb128: how did you check that the datetime was in sync while the indicator was since it's re-syncing quickly [15:39] oh, good point, so "no, it's not resyncing my plugged" [15:39] seb128: or did you just connect it, then check [15:39] I did connect and check [15:39] ah [15:40] mh [15:40] it took like 45 seconds before having it updated [15:40] I had time to poke around and run the command several times [15:41] dednick, ok, in fact just having it [15:41] seb128: i know that indicator-datetime goes to sleep sometimes when the screen is off (charles, this is correct right?). So i'm just wondering if it's that. [15:41] my device says :39 [15:41] I connected to usb, no update [15:41] still outdated [15:41] seb128: can check process state of indicator-datetime? [15:42] seb128, is this the issue? https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/1359802 [15:42] Ubuntu bug 1359802 in indicator-datetime (Ubuntu) "header's timestamp can take a minute to update after resume from suspend" [High,In progress] [15:42] dednick, if the indicator was not running, then the "--object-path /com/canonical/indicator/datetime --method org.gtk.Actions.Describe phone-header" would be outdated [15:42] charles, yes [15:43] seb128, dednick, that one's on my short-term TODO after the brightness slider in i-power [15:43] seb128: erm, well it would resume the process through dbus call no? [15:43] dednick, well, that's not enough to have the unity synced thoguh [15:43] I can call the dbus check, get a result [15:43] and still see unity outdated [15:44] seb128, if unity is out of sync with the service, that's not the same as 1359802 [15:44] charles, indeed not [15:44] charles: yeah, the header seems to be correct [15:44] dednick, one other thing I noticed that might be related [15:44] dednick, charles, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1365530 [15:44] Ubuntu bug 1365530 in unity8 (Ubuntu) "Time in indicator out of sync on resume from suspend" [High,Triaged] [15:44] dednick, when you get a push notification in the notification center menu [15:44] seb128: and calling that dbus method doesn't cause the resync? === alecu is now known as PyAr [15:45] dednick, need to check again to be sure, but iirc no === PyAr is now known as alecu [15:45] seb128: ok. thanks [15:45] dednick, the LED doesn't light up until you turn the screen on [15:45] LED? [15:45] Saviq: ah. [15:46] Saviq: you mean the notification LED? [15:47] dednick, charles: hum, just tried, in that case the indicator dbus info was outdated [15:47] so maybe several issues there [15:48] seb128, how far out of date? [15:48] >1 minute? [15:48] charles, 3 minutes [15:49] dednick, yeah [15:49] it displayed 44 where time was 47 [15:49] seb128, you queried indicator-datetime on dbus and it returned a time that was 3 minutes off from the wall clock? [15:49] charles, correct [15:49] $ gdbus call --session --dest com.canonical.indicator.datetime --object-path /com/canonical/indicator/datetime --method org.gtk.Actions.Describe phone-header [15:49] ((true, signature '', [<{'title': <'Upcoming events'>, 'visible': , 'label': <'17:44'>, 'accessible-desc': <'17:44 (a retourné des alertes)'>, 'icon': <('themed', <['alarm-clock', 'alarm']>)>}>]),) [15:49] [15:49] where computer was on 17:47 [15:49] seb128: ! [15:49] which is the time the phone displayed 15 seconds later [15:50] i'm going to start blaming indicator-datetime ;) [15:50] lol [15:50] seb128, that's a variation on this theme that I haven't seen before. Is it still happening for you? [15:50] dednick, well, I had cases where the indicator info was right but the unity ui was behind [15:50] charles, "still"? [15:50] the phone is awake now [15:50] let me a few minutes [15:50] but it happens consistently enough [15:51] like I've been 3 occurences in the 15 minutes where we started discussing that [15:51] seb128, we've discussed this before but in the past iiuc it's always been unity8 and indicator-datetime being out of sync with each other [15:52] rather than datetime being (>1 min) out of sync with the wall clock [15:52] seb128, could you please write up how to reproduce that in #1359802 and I will investigate today [15:52] charles, how to reproduce? "wake up your phone, look at the clock" [15:52] not sure what else to write [15:53] charles, [15:53] http://paste.ubuntu.com/8319927/ [15:53] just tried again and got ^ [15:54] basically "press power button to suspend the krillin, unplug from usb, wait a few minutes, press power button, notice time is off, plug usb cable, adb shell and run commands" [15:54] ack [15:55] I don't understand why it would lag behind like that [15:55] it's easier to explain not updating at all [15:55] but how can it lag 3 minutes behind like that? [15:56] I'm happy to help getting debug info if you tell me what to try/do [15:56] charles, well, it might be "not updating", 3 minutes is about the time I let it on the desk while typing on IRC [15:56] hum, just woke it up [15:56] it was on :54 [15:56] when I turned it off at :53 [15:56] and it should be :56 [15:57] ok, just turned :57 [15:57] * seb128 turns off and wait another 5 minutes [15:57] seb128, so, maybe I'm not asking the question right: [15:57] 1359802 is about not updating the clock for [1..60] seconds after we wake up from sleep [15:58] so if the clock went to sleep at :45 and you woke it up at :50, it might still read :45 for up to 60 seconds [15:58] k === dandrader|afk is now known as dandrader [15:58] that might be what I'm seeing here [15:58] so I'm less worried about the size of the offset there (5 minutes) than the time to update (<=1 minute) [16:01] seb128, if it "fixes" itself in <=1 minute after wakeup then we're still talking about the known bug in 1359802 [16:01] charles, ok, let's assume it's that and see if some issue is remaining once that's fixed [16:01] ack [16:02] charles, but I had cases some ~10 days ago where the indicator time was right on dbus but the unity ui was not [16:02] after that lands I'll start blaming dednick again [16:02] but let's do one issue at tim [16:02] e [16:02] seb128, there was one fix for that a couple of weeks ago that I think dednick landed already [16:02] right [16:02] seb128, that was around the same time that the datetime indicator was showing up completely empty [16:02] I had that fix for sure [16:02] it was like a week after the fix landed [16:03] ugh [16:03] jibel confirmed that [16:05] i'm wondering if fixing 1359802 will just hide the other problem by forcing a reconnection or something [16:07] i'm sorting out my krillin device now. hopefully will be able to put some logging in to find out what's up. [16:07] if i can reproduce it :) [16:09] bug #1359802 [16:09] bug 1359802 in indicator-datetime (Ubuntu) "header's timestamp can take a minute to update after resume from suspend" [High,In progress] https://launchpad.net/bugs/1359802 [16:11] Saviq: ya, it's possible there are 2 bugs [17:09] bregma: hi, I think we're good to go with this now. I've fixed all of Saviq's concerns: https://code.launchpad.net/~mzanetti/unity/new-key-in-launcher-schema/+merge/232199 [17:09] bregma: what do I need to do to get this released? [17:10] mzanetti, you just wait until I do the next Unity landing (soon...) [17:11] bregma: ok, cool. thanks. Can you ping me when it happened so I can release the unity8 related changes for it? [17:11] mzanetti, sure [17:11] cheers === dandrader is now known as dandrader|lunch === dandrader|lunch is now known as dandrader [18:24] greyback, still there? [18:24] dandrader: yeah [18:25] greyback, For the MirSurfaceItem test in qtmir I'll need to create a QGuiApplication and a QQuickWindow, just to be able to send touch events to it via QTest::touchEvent() (unless I abstract that away, but I would rather not) [18:26] greyback, so is that a problem is qtmir's "make check" has such a "UI" test? [18:26] dandrader: probably yes. We want those tests to run on a headless system [18:27] dandrader: I wonder what my Mir guys have [18:28] greyback, so I would need that xvfb setup... so much work [18:28] a mock mir server that doesn't talk to hardware would do [18:28] is this testing Mir stuff? You need the mirserver QPA? [18:29] greyback, did you read my first sentence? :) [18:29] dandrader: I don't understand what you're trying to test [18:29] greyback, I think I will just abstract away MirSurfaceItem::touchEvent() for now. enough for me to test the touch sequence validation thingy [18:30] greyback, a scheme similar (but simpler) to what was done for QtEventFeeder [18:30] ok [18:30] greyback, if you disable an item that is currently receiving a touch sequence [18:30] greyback, that item will never get a QEvent::TouchEnd for that sequence [18:31] greyback, QQuickWindow won't send it [18:31] greyback, sounds like a QT bug, although I wouldn't be surprised if they say that you shouldn't disable a touch owner in the first place [18:31] dandrader: /me surprised by that. How does a MouseArea deal with it? [18:31] (this kind of stuff) [18:32] greyback, so I'm adding this touch sequence validation before forwarding touch events to the mir surface [18:32] greyback, so things keep working regardless of whether qt fixes that or not [18:32] ok, I understand what you're doing at least [18:33] am just curious, can MultiPointTouchAreas be confused in a similar fashion? [18:33] greyback, the right question is: how does a client-side QQuickWindow deal with it? [18:34] it presumably just waits for the TouchEnd [18:34] greyback, its mouse event emulation gets stuck, just like unity8's QQuickWindow without that qteventfeeder fix [18:34] dandrader: could this go in qtubuntu then? [18:34] similar event processing that you added to qtmir [18:35] greyback, it could. but I chose to put it in MirSurfaceItem. fixed earlier in the flow of events [18:36] dandrader: I just think of using qt apps with another mir server - they would potentially exhibit the same problem? [18:36] dandrader: it probably should be fixed in MirSurfaceItem yes, as other toolkits may have the same difficulty [18:37] greyback, you could add validation on both sides [18:37] dandrader: keep doing what you're doing anyway. Can look at qtubuntu if we actually see a need to fix that [18:38] greyback, the next step, if we have the time, would be to tackle that issue in Qt itself: reporting a bug and proposing a patch [18:38] dandrader: right [18:38] greyback, more important than a qtubuntu-side validation imho [18:38] and presumably getting Mir to behave better :) [18:39] greyback, that's what racarr is doing if I'm not mistaken [18:39] him and RAOF === Malinux_ is now known as Malinux === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === salem_ is now known as _salem