[00:14] hey guys, good morning, does anyone know how to start unity using startx? i have tried to put in `exec unity`, unity started but lot of things were missing, compiz wasn't loading, etc.. [00:15] also tried `exec gnome-session --session=unity`, couldn't get unity to start [00:16] I personally don't want to use any of the display manager, so is there a way to just startx it? thanks [07:10] mzanetti: is https://code.launchpad.net/~mzanetti/unity8/update-inputinfo/+merge/273248 something we want in or still a WiP? [07:43] tsdgeos, still WIP. need to update tests... have them half working here [07:43] ok [08:14] mzanetti: so no need for the extra carefulness i suggested in the autorepeat MR? [08:14] i guess it was a bit too much :D [09:13] mzanetti, you got an arale? can you try bug #1508830 ? [09:13] bug 1508830 in unity8 (Ubuntu) "Phone hangs by repeatedly refreshing the apps scope and taking screenshots" [Undecided,Confirmed] https://launchpad.net/bugs/1508830 === nudtrobert1 is now known as nudtrobert === jzheng is now known as jzheng_afk [10:08] sigh [10:08] something has changed on the SDK [10:08] and stuff now doesn't even compile [10:11] in the use_sdk_13 bnranch [10:12] * tsdgeos investigates [10:14] ah new item clashes with one of ours [10:14] tsdgeos: blame Saviq, it won't fix it but you'll feel much better [10:35] Saviq: mzanetti: are you guys doing the audiorole compatibility branch with that loader thing you showed me yesterday or want me to? (since the bug is assigned to me) [10:37] tsdgeos, you might very well do it, basically take the component from https://code.launchpad.net/~mzanetti/ubuntu-clock-app/detect-qtmm-version/+merge/275177 [10:37] ok, /me does [10:37] oops... sorry, missed your earlier message Saviq [10:37] nw [10:38] Saviq, yes, I have, will try, (re arale) [10:38] mzanetti, jibel was able to repro once, there's a chance the "refresh apps scope" is a red herring [10:38] I wasn't able to repro on krillin with, or without apps scope refresh [10:49] yeah... looks like something goes wonky on dbus [10:50] media hub dying and the shell trying to reach it for the screenshot sound [11:12] man... DST change this weekend "16 trains will stop for an hour"... [11:13] lol [11:14] can we please stop this madness [11:15] I agree but this change is to the right time [11:16] ok then, can we please only do this this one last time? === olli_ is now known as olli === alan_g is now known as alan_g|lunch === dandrader is now known as dandrader|afk === maclin1 is now known as maclin === dandrader|afk is now known as dandrader [12:59] mterry: can you review https://code.launchpad.net/~aacid/unity8/scope_settings_keyboard_scroll/+merge/274874 ? [12:59] k [13:01] tsdgeos, I wanted something like this in one of my apps but was too lazy to do it :) [13:01] tsdgeos, SDK should have an option on its UbuntuListView for this [13:02] the problem is that it still needs the delegates to request the visibilty [13:02] ideally one could watch all children created and inject the request [13:02] but i decided not to spend so much time :D [13:03] tsdgeos, why this line in setMake...Item()? "d.previousVisibleHeight = d.visibleHeight;" [13:03] is it for the initial setting? could do that by "property real previousVisibleHeight: visibleHeight" [13:04] tsdgeos, also, mightn't you want to ensure it's visible in that same call without having to wait for visibleHeight to change again? [13:05] mterry: this is reusing some of the code we use for the previews [13:05] in which the items change height so we need to account for that [13:05] hence the complex stuff with height [13:05] tsdgeos, ? but in onVisibleHeightChanged you always set previous. So the only time previous will be out of sync will be before the first onVisibleHeightChanged [13:06] tsdgeos, in which case you can just start with an initial binding on previous [13:06] mterry: yes i set it for the next change [13:06] that's what previous is for, no? [13:07] tsdgeos, right. I'm saying I don't see the need for the additional set in setMakeSureVisibleItem(). But it doesn't matter. It's not harmful. Just hard to see why it's there [13:07] mterry: otherwise the first onvisibleheightchanged has un-initialized value, no? === alan_g|lunch is now known as alan_g [13:08] tsdgeos, right. And that's why I suggested "property real previousVisibleHeight: visibleHeight" instead of ": 0". Thought it was clearer than an extra previous set [13:08] But it doesn't matter [13:08] mterry: but then it doesn't work for the next item [13:08] since the binding would already be broken [13:09] tsdgeos, but previousVisibleHeight doesn't depend on the item. The next item will have it set from a onVisibleHeightChanged call [13:11] hmmm, might be [13:11] tbh i just moved this code around :D [13:11] tsdgeos, I'm seeing that now :) You just kept the set from the previous code [13:12] tsdgeos, wouldn't it be better to adjust contentY immediately when setMakeSureVisibleItem() is called, rather than waiting for the next onVisibleHeightChanged? [13:13] to which value? [13:14] tsdgeos, I mean, force a recalculation, as if onVisibleHeightChanged happened [13:14] tsdgeos, but just to do it immediately after receiving a new item [13:14] but at that point it won't do anything [13:14] since you're already visible [13:14] since you gained focus [13:14] tsdgeos, how does this component know that? [13:14] so the user can see you [13:15] tsdgeos, you're saying that all callers make sure to only call it after they are visible? fine [13:15] tsdgeos, but as a component API, I'd have expected it to make sure [13:16] well it's a component since i didn't want to c&p code :D [13:16] Seems less fragile to not rely on callers being smart [13:16] it doesn't matter anyway [13:16] since it'll work [13:16] on the height change [13:16] if somehow you can make a thing gain focus without having it in view [13:19] tsdgeos, you're talking about the specific narrow situations we use this component in now. But I'm just seeing a component that has an API that says "make me visible" -- no API contract for being focused or in view. [13:19] tsdgeos, I'm thinking a future unity8 developer might reasonably use this for a different purpose and expect its API to do what it says [13:19] mterry: sure, as said, it'll get visible on first height change by the sdk [13:20] tsdgeos, right... [13:20] not as you'd see the difference at all [13:20] tsdgeos, and I'm saying there's a gap there before that happens :) [13:20] this is a theoretical problem, I'm just trying to be defensive against future bugs/misunderstandings [13:20] i don't understand what you say [13:20] i don't see any theoretical problem [13:21] please explain where is the problem [13:21] tsdgeos, so let's say in a year, I see this component. I have some code that wants to pull a widget in my list into view. So I call this setMakeSureVisibleItem(). And nothing changes! It's not in view. Only the next time the OSK appears does it finally scroll to my widget [13:22] correct [13:22] tsdgeos, why would setMakeSureVisibleItem() not make sure my item is visible after the call? :) [13:22] because you're using a component called ListViewOSKScroller [13:22] you're doing it wrong [13:22] it's not what you want [13:22] and it should not do that [13:23] Oh fair, OSK is in the title... But fine. What if I call this after the OSK is up? [13:23] if you want to make an item visible there's other things to use [13:24] tsdgeos, but now there's a race between the OSK and this API call. What if I call this after the OSK appears? [13:24] i'd still argue you're using it wrong [13:24] it's not what the component is for [13:24] Says every widget designer :) [13:24] this is *not* a widget by the way [13:25] it's a helper [13:25] I know [13:25] if it doesn't do what you want [13:25] don't use it [13:25] Says every API designer :) [13:25] it's not like you're forced to use it [13:25] that's silly [13:25] you're forced to use a button [13:25] so button has to be flexible [13:25] you're not forced to use this, so it can do its thing [13:25] if it doesn't do what you want, you can still do it [13:26] you're not being excluded [13:26] so yes, this component doesn't do what you want when the OSK is open [13:26] that's what it has been coded to do [13:26] it's not a bug, it's a feature [13:26] Right... It seems needlessly fragile is all. But sure, I'm not saying there's a bug in the code right now. Just trying to be defensive [13:26] it is not needlessly fragile [13:27] doing one thing well it's easier than doing more things we don't need to do [13:27] introduces more bugs [13:27] i need extra code to make a use case we don't need to work [13:27] i agree with you that it needs documentation though [13:27] we can go back to the version that copies the code ;) [13:28] It'd be one line of code after refactoring onVisibleHeightChanged into a function. But sure [13:28] mterry: it won't [13:28] tsdgeos, I feel like this is a more heated argument than I intended to bring up [13:29] i'm sorry for trying to counterargue your arguments [13:29] :D [13:30] tsdgeos, no that's fine :) [13:30] tsdgeos, you say it won't be one line of code? Maybe that's the confusion. What are you envisioning I'm suggesting? [13:31] (I was thinking move onVisibleHeightChanged logic into a d.doTheThing() method. And just call d.doTheThing() after setting a new item to watch) [13:31] tsdgeos, ^ [13:32] you need to at least split the if into two [13:32] since you have previousVisibleHeight > visibleHeight that won't work if you don't [13:33] tsdgeos, sure... so onVisibleHeightChanged becomes "if (previousHeight > nowHeight) doTheThing(); previous = now;" [13:34] tsdgeos, like, this is a super minor point. I didn't mean to start a 30min debate about it :) [13:34] i just wanted to not have a discussion about code i just moved around [13:34] tsdgeos, it's fine if you don't think it's worth the bother. I just felt I had to explain my side of things and then we got here [13:35] tsdgeos, well I think there's a higher standard for standalone components than code that gets used in one place [13:35] sounded it was the safest solution not to change code we already have and works [13:35] tsdgeos, small bug I noticed in new navigation [13:35] tsdgeos, try searching in music scope where there is no departments [13:36] tsdgeos, then clear the search [13:36] then tap the search again so you see recent searches [13:36] mterry: i can move it to Dash/ instead of Components/ if it makes your "standalone compoennts" worry better? [13:36] we miss the shadow at the bottom of the box [13:38] tsdgeos, no that wouldn't change anything :) But like I said, this is fine as is. I get that it's code you are just moving. (I don't think that means you absolve all responsibility for that code, but I understand reluctance to change it) [13:40] tsdgeos, like when you make a bug fix and a reviewer asks you to refactor the component :) [13:41] I hate that :) [13:42] mterry: so want me to add some documentation to the qml file saying what the component does? [13:43] tsdgeos, the answer to that question is always yes, even without a debate as a prompt ;) But I don't think it's required here, if existing usage is documentation enough [13:44] well there's no documentation at all [13:47] tsdgeos, just noticed another place where this would be useful -- the authentication dialog to sign into U1 from the dash scope, when you need to give a two-factor code. No need to change your branch, but just saying, a useful component [13:47] mterry: but that's not in unity8 so can't be used [13:47] sure it's an useful component if done better in the SDK [13:47] as we started the discussion with :D [13:47] tsdgeos, right, that's what I was saying at the start :) [13:53] tsdgeos, also, when I am in a department and I search, the text is higher [13:53] cimi: what do you mean "the text is higher"? [13:53] in the search bar? [13:53] tsdgeos, yes [13:53] tsdgeos, not vertically aligned [13:53] cimi: that already happens today [13:54] aw ok ) [13:54] i'd say [13:54] please double check [13:54] afaik gets fixed when moving to sdk 1.3 for some reason [13:54] tsdgeos, yeah all text is higher now [13:54] seems sdk bug [13:55] Mirv: there? [13:56] tsdgeos, did you see the other bug of the shadow? [13:56] cimi: i am having a look at the 5.5 multimedia thing so don't have the silo installed [13:56] i've copied your text and will check later [14:01] tsdgeos: barely but yes [14:02] tsdgeos: FYI I just filed bug #1508945 ie the weather app misbehaves still with 5.5.1 (similar to what it did when I backported certain patches fixing 1470700 to 5.4.1) [14:02] bug 1508945 in Ubuntu Weather App ""Couldn't load weather data, please try later again!" with Qt 5.5.1" [Undecided,New] https://launchpad.net/bugs/1508945 [14:02] or maybe appaarmor is coming into the way or something. but other apps don't seem to have network issues. [14:03] Mirv: cool [14:03] tsdgeos, what tool is the //! syntax for? or is that just stylistic? [14:03] mterry: it's doxygen [14:03] tsdgeos, ah makes sense [14:03] i think [14:03] or maybe qdoc [14:04] one of the two :D [14:04] doxygen afair [14:04] tsdgeos: all UITK issues start to be resolved. oh and btw I'm away next week (Saviq too fyi), but it's getting reasonably closer to landing to xenial now [14:04] Mirv: :) [14:04] Mirv: the new silo has 5.5.1 but still with the audiorole patches, right? [14:05] tsdgeos: yes, still with audio role patches [14:05] tsdgeos: and qtubuntu-camera/media ported to it [14:05] ok, i'm having some issues, will double check what i'm doing wrong [14:05] tsdgeos: so Unity 8 would appreciate a patch so that people would not need to hand edit qml files (as guided at https://wiki.ubuntu.com/Touch/QtTesting though) [14:05] yeah [14:05] on it [14:06] videos, camera work too again as of today. I've been filling some holes of rebuilds needed today after I copied the 5.5.1 there. [14:06] now it's pretty complete aside from qtcreator still building for the desktop. [14:09] i'm getting [14:09] file:///home/phablet/main.qml:6 "Audio.audioRole" is not available in QtMultimedia 5.5. [14:09] wonder what is wrong?¿ [14:10] * tsdgeos starts all over [14:10] tsdgeos: the revision: 1; I asked about in the bug report maybe? [14:11] mzanetti: Saviq: did you guys actually test https://code.launchpad.net/~mzanetti/ubuntu-clock-app/detect-qtmm-version/+merge/275177 ? [14:11] with our 5.5 packages? [14:11] porting seemed alright for c++ code but I didn't know what to do on the qml side [14:11] tsdgeos, I di'in, since I disapproved it ;) [14:11] Mirv: tbh i'm not totally sure what that revision does [14:12] Saviq: k [14:13] tsdgeos, I think you can have multiple implementations of the same method, of different revisions, exported in different versions [14:13] or something like that [14:14] Mirv, ↑ [14:14] mzanetti, can you comment what you found on bug #1508830 please [14:14] bug 1508830 in unity8 (Ubuntu) "Phone hangs by repeatedly refreshing the apps scope and taking screenshots" [Undecided,Confirmed] https://launchpad.net/bugs/1508830 [14:15] tsdgeos, Mirv, http://doc.qt.io/qt-5/qtqml-cppintegration-definetypes.html#type-revisions-and-versions [14:15] does anyone know how to make bluez dist-upgrade not stall forever? [14:16] Saviq: yeah, I just douldn't figure out how to actually use it. and I was on that doc page :) [14:17] Mirv, what you do is have implementations marked by Q_REVISION(), then, as you qmlRegisterType, you supply that for version foo, revision bar should be exported, for version baz, revision blah [14:17] Mirv, this way from a single component you can export multiple versions of an import [14:17] Mirv: i'd say we miss part of the patch [14:17] let me check [14:17] Saviq: yeah, thre's no qmlRegisterType in the patch (http://anonscm.debian.org/cgit/pkg-kde/qt/qtmultimedia.git/tree/debian/patches/Add-audio-role-API-to-QMediaPlayer.patch?h=ubuntu) [14:17] tsdgeos: it's the whole commit at least [14:18] Mirv, it could be that the 5.5 import is marked for revision(1) earlier [14:18] or maybe the patch is wrong upstream too [14:18] i.e. qmlRegisterType for 5.5 was already there, with revision 1 [14:18] or well, that [14:18] but then, because it defaults to 0 [14:19] it's possible upstream didn't test the qml part when they merged it to 5.6.. [14:19] if there isn't a 5.5 import registered with revision 1, then audioRole shouldn't be available [14:19] but .qmltypes says otherwise [14:20] yeah they have [14:20] qmlRegisterType(uri, 5, 6, "Audio"); [14:20] but for 5.6 [14:20] Mirv, what does `qmlplugindump QtMultimedia 5.5` say? [14:20] which is the correct version the upstream patch is being added [14:20] so 5.5 exports a 5.6 version [14:21] weird, but not necessarily wrong [14:21] no we're doing it ourslves [14:21] just means to use audioRole we actually need to import 5.6 [14:21] not upstream, no? [14:21] no means our backport is incomplete and we need a [14:21] oh right, *we* backport to 5.5 [14:21] qmlRegisterType(uri, 5, 5, "Audio"); [14:21] and the mess continues :D [14:21] yay [14:22] tsdgeos, we could leave it as 5.6 [14:22] but i'd say that should be good [14:22] or that [14:22] tsdgeos, noting that the only feature available there over 5.5 [14:22] is audioRole [14:22] I'd go for that [14:22] it's like we partly have 5.6 [14:22] then we don't need to migrate to 5.6 proper [14:22] exactly [14:23] assuming 5.6 is backwards compatible :) [14:23] actually we have it already :D [14:23] boo me [14:23] yes, we do [14:23] so with the import for 5.6 it should work [14:23] let's see [14:23] tsdgeos: ok so there's another MP in addition to https://codereview.qt-project.org/#/c/122658/ ? [14:24] and we miss that [14:24] file:///home/phablet/main.qml:3 module "QtMultimedia" version 5.6 is not installed [14:25] tsdgeos: I've sed 's/5.5/5.6/ in that ^ when backporting [14:26] we still have [14:26] // 5.6 types [14:26] qmlRegisterRevision(uri, 5, 6); [14:26] qmlRegisterType(uri, 5, 6, "Playlist"); [14:26] qmlRegisterType(uri, 5, 6, "PlaylistItem"); [14:26] in the code [14:26] wait tha error i got was with the wrong qt installed :D [14:26] i'm confusing myself now [14:27] give me 30 min to regather my thoughts [14:27] tsdgeos: playlist is different backport/patch [14:27] i know [14:27] still says "audio" in there [14:28] Saviq, I didn't really find much... took like 30 screenshots and can't reproduce the hanging [14:29] also tried the scope refreshing... no avail [14:29] reading jibel's log output suggests media hub is not responding on dbus and we try to play the screenshot camera sound [14:29] ok, I guess that qualifies... [14:29] will add this [14:30] mzanetti, ah I thought you actually saw the media issue [14:39] no, sorry [14:40] no need to be sorry :) [14:41] new inputinfo api is great [14:41] could drop all the wrapper stuff etc... also mocking was super easy [14:41] ljp, ^ [14:52] nice === Cimi_ is now known as cimi [15:07] mzanetti, so the "reveal sensitivity" of the edge push to showing the launcher should be configurable. what's the prefered way to expose it? gconf? [15:08] Mirv__: https://code.launchpad.net/~aacid/unity8/new_and_old_audio_role/+merge/275365 should be it [15:08] need to triple check [15:08] but looks good to me [15:08] arg it has a stray commit === mariogrip_ is now known as mariogrip [15:10] better === Mirv__ is now known as Mirv === dandrader is now known as dandrader|afk [15:21] tsdgeos, our packages that have the feature backported to 5.5, will they also bump the version to 5.6, even if it's 5.5? [15:22] mzanetti: yep [15:22] ok, that's weird [15:22] or at least that's what the current packages have [15:22] are they backporting *all* 5.6 changes? [15:22] don't think so [15:22] but if we do use 5.5 [15:22] why bumping the version then? [15:22] then it'll be even more weird [15:22] because we'll need revision 2 for 5.6 [15:22] and then all is evil [15:23] not following... [15:24] we can say 5.5 supports Audio Revision 1 [15:24] or [15:24] 5.6 supports Audio Revision 1 [15:24] upstream is the second [15:24] if we do the first, we're also lying [15:25] i actually think it makes more sense to say we've backported parts of 5.6 [15:25] and act accordingly as 5.6 will act [15:25] so we need to change less things later [15:26] it's all "wrong" dependening how you want to think it [15:27] we don't support all 5.6 [15:27] but 5.5 doesn't have audioRole either [15:27] but at least the core is more "correct upstream" if we say 5.6 [15:27] in the sense it'll work on other non ubuntu-patched Qts [15:27] fair enough... [15:28] well, if other apps check for 5.6 and end up with our patched 5.5 version there's no guarantee it'll work [15:28] tsdgeos: so should I revert the http://anonscm.debian.org/cgit/pkg-kde/qt/qtmultimedia.git/commit/?h=ubuntu&id=8b95cbe6b78041047ac0a993b8986e6e836c719c which is currently in the package? [15:29] Mirv: i'd say so since it's misleading [15:29] ok, rebuilding qtmultimedia then [15:29] mzanetti: sure not for other code [15:29] but for ours it will [15:29] at still the lib is called 5.5.1 [15:29] tsdgeos, in any case, we're just going to drop the audioRole usage in the clock app too [15:30] even it partly supports things of 5.6 [15:30] right... got it... [15:30] mzanetti: i agree it's "bad" both ways [15:30] yeah... [15:30] well, distro-patching :) [15:30] but i'd say that calling 5.6 is the less bad of them [15:34] tsdgeos: ok qtmultimedia building, unity8 building at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-012/+packages [15:34] I really should stop now, bad way to start vacation totally exhausted :) there's tomorrow still. [15:35] see you tomorrow [15:36] bregma: any new puritine packages I can try out? [15:36] mhall119, nope, all the fighing is happening on other fronts right now [15:38] ok, let me know when there is and I'll give it a try === g4mby is now known as PaulW2U [15:39] cimi: yes, can repro the shadow thing [15:39] tsdgeos, good [15:45] cimi: fix pushed [15:46] greyback: i added the comment you wanted, https://code.launchpad.net/~aacid/unity8/fix_cropped_image_binding_loop top approve? [15:47] done [15:50] greyback: tx [15:51] larsu: top approve https://code.launchpad.net/~aacid/qmenumodel/clazy_run/+merge/272788 ? === ssweeny` is now known as ssweeny === dpm is now known as dpm-afk === dandrader|afk is now known as dandrader [16:56] the link http://cdimage.ubuntu.com/ubuntu-desktop-next/daily-live/ is broken === charles__ is now known as charles [17:41] bregma: ^ see the darklight ping, so do we need to remove something there ? [17:42] kgunn, it looks like darklight_ has a bookmark to something that no longer exists [17:43] bregma: mmm, will go back to my tinkering === robru|sick is now known as robru === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader